Based on our previous blog, creating off-chain proofs, there might be the possibility to create a blockchain algorithm where you can actually delete. For the architecture we defined the following architectural considerations:
- The nodes taking part in the consensus should have an identity, a private and public key key pair where the private key is kept secret.
- The consensus must be implicitly or explicitly based on a quorum, meaning that two thirds of the nodes should sign a given piece of information with validity.
- The consensus can be an indirect quorum, like in Tendermin, where there are several rounds for the consensus, like one for choosing a leader node and proposing a block and a second one for validating the given node by a quorum.
- On-chain governance must contain a transaction that adds new nodes of the system. After successfully adding a node to the system, the public key of a node (e.g. identity of a node) must be added to the blockchain.
- The blockchain in a classical sense contains only governance information, e.g. the public keys of the different validator nodes.
- There must be a mechanism and a special transaction for deleting validator nodes from the blockchain, like with the help of an explicit transaction, or with the help of an automatic mechanism, like if a validator does not sign a block for an amount of time, it will be deleted from the active validators.
- The architecture prefers consistency against availability at network separation, so it can not be forked and can not be long range attacked, unless more than one third of the nodes private key is leaked.
- Efficient network separation is a working denial of service against the architecture.
- Non-governance information, like smart contracts, or cryptocurrency transactions must be built up in a account-state based fashion, meaning that for a getting a valid state of the system, it is enough to read the last valid state.
- Non-governance information is not stored in blockchain but in a separate block that is stored off-chain and validated by an off-chain proof by the blockchain, see the following picture
:
- Validator nodes have a two level key mechanism: master key is the main key of the node, but in each round, the node creates a new private - public key pair where the public key is published into the blockchain. This round key is used to sign off chain blocks.
- At each round validity of the off-chain information and data is validated by all of the validator nodes and signed by the public keys that are specific for a certain round.
- An external observer can check if a given block is valid, by checking the public keys of the validator nodes and checking if they really signed the given block. As public keys are individual for each round, both the exact round and the fact if a given block is the last one can be easily identified.
- At signing an external block, there can be different strategies defined, like checking the last block or validating the last couple of blocks.
- Nothing guarantees that the external external block are stored. As it is on the one hand an advantage, because this way old information can be deleted, it is a drawback as well, because nothing guarantees that the old blocks are actually stored.
- There should be a mechanism that guarantees that the given last nodes are stored somewhere. This mechanism must crash fault tolerance, but not necessarily Byzantine, because based on the block proofs it can identified if the block is valid.
- The storage mechanism and probably the whole infrastructure as well must be supported by a cryptoeconomical incentive mechanism.
- The algorithm should have an economical incentive mechanism that slashes or discourages nodes signing more than one blocks on a round.
