gradido/docu/other/system-notes.md

- understanding of the system
  - abstract, conceptual model
    - levels
      - a ledger with user transfers (userA, userB, amount) and money
        creations (user, amount)
      - each ledger has certain rules (for example, transfer cannot
        happen if sender doesn't have enough funds; or creation sum for
        single user cannot exceed certain amount); by applying those
        rules all transfers in the ledger can be replayed and ledger can
        be deemed "plausible"
        - this alone is NOT enough to confirm that transfers actually
          happened, there has to be more to that (transfers have to be
          authorized in one or another way)
      - multiple such ledgers (blockchains, groups), each maintaining set
        of users inside group
      - groups can befriend each other, allowing cross group transfers
        between users
      - users can migrate from group to group
      - so, a set of rules exist for a group (for example, user has to
        be inside of the group to participate in that group's transfer;
        groups have to be friends for cross-group transfer to happen;
        etc.); this allows full replay and checking if ledger is
         plausible
  - such model could be implemented in various ways, for example, single
    server, single thread database application, or even with hand-written
    ledger, served by an accountant
    - idea is to put that together with concept of distributed network,
      with nodes, messages, etc.
      - from that comes choice to use Hedera, then Protobuf, C++
   - any solution should involve user authentication of some sort;
     public/private key signatures is a convenient choice
- hedera: pros and cons
  - pros (some are essentially needed features):
    - ordering of transactions
    - transaction sender is authorized
    - defense against flood with help of HBARs (their currency)
    - transactions are distributed
    - emerging industry standard
  - cons:
    - risk of sudden changes; for example, if Hedera decides to use
      different running hash calculation algorithm without prior notice,
      all network goes down
    - not all features are good, some are missing
    - their server uptime is not guaranteed
    - future is not guaranteed as well; what if after 5 years Hedera is
      shut down?... at that point there could be million transfer
      blockchains, built on top of it
      - that could be solved, though, by replaying transfers into new
        ledgers, etc.; still worth to consider
    - when connecting to hedera network only way to get current sequence
      id and running hash is to use getTopicInfo() call, which costs
      HBARs
- gradido node
  - hosts ledger data, therefore most important part of the system
    (kind of backend database)
  - performs data checks before insert, replays blockchains on restart
  - exchanges information with other nodes, requesting and sending
    blockchain data when necessary
  - provides blockchain data in convenient way for node users
  - listens to transaction data coming via Hedera network
    - all transactions are therefore stored in blockchain, regardless if
      they are possible and correct or not; hedera message sequence id
      list won't have holes in it
  - calculates fields when it is necessary (such as transaction result
    or "verdict"; for example, transfer may fail if user doesn't have
    enough funds
  - in its validation procedures implements all blockchain rules
    - transaction format allows format / rule versioning
  - can host multiple blockchains
    - actually, needs to host multiple blockchains for cross-group
      transfers
  - expects node user to provide other node endpoints and list of
    blockchains to maintain
    - otherwise, not conceptually strongly bound to user; it can be
      anything, for now there are two services, login server and
      community server
  - data is kept on hdd in a binary, yet simple, struct-like format;
    it is split in same sized blocks; all records have same length
- problems
  - user authentication
    - if a user can have more than one account, it opens way for creating
      of bot networks, essentially robbing honest players
      - user migration and cross group transfers would allow many ways
        to create bots
    - on the other hand, hardcore user authentication may scare off
      people
- conclusions
  - set of rules, allowing blockchain to be replayed, has to be very
    clearly defined (and considered)