RFC005: Summary of issues with protocol v1

[reinkrul]

This issue is a list of all issues of protocol v1 we've identified and should be adressed in v2.

Network layer depends on application layer

TXs can be signed with keys that were published as JWK embedded in the TX or with a key that was only published in a DID document. The latter is a problem, because it makes the network layer dependent on the application layer (VDR, in this case):

• Part of receiving a transaction is validating its signature, but when the processing of DID documents stalls, TXs that are signed with keys published in (yet) unprocessed DID documents will fail.
• It makes it impossible to implement a simple Nuts node that just acts as a network gateway/gatekeeper without implementing the complex layers (VDR/VCR/etc) built on top of the network.

Possible solutions:

• Require all keys that are used to sign TXs to be published as JWK embedded in the JWS (once).

Missing TX payload blocks processing

While the network layer can build the DAG regardless TX payload being present or not, the application layer only processes succeeding transactions when the payload of all preceding TXs is present. Problems:

• Adds complexity because payload retrieval has to be retried.
• Its unknown which nodes have the payload of a certain TX, so it has to broadcast the query to all peers, adding lots of chatter.

Possible solutions:

• When retrieving transactions from a peer, it should respond with both transaction and payload. The node can then atomically add the TX + payload to the DAG, asserting both are present.

Synchronizing out-of-date DAGs takes a long(er) time when the DAG grows

Reasons:

• When a difference is detected between the local and remote DAGs (by comparing the block's hash) the complete block is requested, which results in all TXs being exchanged (which can be quite a lot). While there may be just one or a few TXs missing on the local node.

Possible solutions:

• Apply an established set reconciliation algorithm, e.g.:
  • https://github.com/AljoschaMeyer/set-reconciliation

Can't exchange private information because of the share-everything-nature

Possible solutions:

• Encrypt sensitive information such that only the intended receiver can decrypt it. Downside: it is still there, and leaked when a private key leaks. The fact that there's encrypted information for a specific party also leaks information in itself, potentially allowing correlation attacks.
• Simply don't exchange information on the P2P netwerk, but do so directly.

Time-based blocks too complex and error-prone

We use blocks for quickly

[reinkrul]

My notes from an earlier assessment:

• Attempts to build a full mesh, which might break down with many nodes
  • Nodes broadcast their last hash to sync (every 2 secs), lots of chatter
  • Filed as Network: support partial meshes #234
• Most semi-public DLTs are block-based and have 'proof' (of work, of stake, voting, etc). We don't, which allows parties to easily add data (the good) but that also goes for malicious parties (the bad).
  • Put on roadmap for 2023
    What's missing;
• Fast replay (from another node) when starting a new node
  • Filed as Network: fast replay when starting a new node #235
• Flooding prevention
  • Duplicate with 2nd point above
• Fast comparison of remote node's graph vs own graph (current implementation just requests whole DAG and compares it)
  • Fixed in v2
• Maybe; more authorisation than just "you need to have a PKIOverheid certificate"?
  • What if a malicious node produces lots (e.g. gigabytes) of crap that clutters the DAG?
  • Put on roadmap for 2023
• Detect dead nodes
  • Filed as Network: garbage collection of dead endpoints #236
• Retrieve transaction payload from other nodes than the one who sent you the hash
  • Fixed in v2 (payload is packed with TX itself, except for private TXs)
• Detect nodes that refuse to sync with you (but keep sending different hashes)
  • Put on roadmap for 2023
    Yet to prove;
• Node discovery using DID service endpoints
  • Fixed in v2

[woutslakhorst]

@reinkrul could you post an updated list with only the items that are still relevant?

[reinkrul]

Each point has been adressed or planned, for the rest I've made an issue.