Notes on off-chain information a blocks

From a practical point of view, if a piece of information can be found in the blockchain, it gives two kinds of a guarantee. On the one hand, the information exist, meaning that at verifying the whole chain, the information has to exist and has to be downloaded, otherwise the consistency can not be identified. On the other hand, the information is valid; actually the whole consistency of the blockchain gives the guarantee if the piece of information is valid. However there might be a solution to guarantee information consistency without the need of giving a guarantee for availability. If a piece of information is signed by the blockchain itself but it is not stored directly in the chain, it gives a guarantee, like an off-chain proof that the information was valid without storing that piece of information directly in the chain. Certainly, the situation will be a little bit more complicated if the blockchain can actually fork.    

#InformationAvailability #InformationValidity

Blueprint of a deletable blockchain platform

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.

Creating off-chain proofs in blockchain protocols

Considering a blockchain protocol, it can be sometimes useful to have a proof that a certain transaction or state was applied to the blockchain, without actually involving this data in the blockchain. Such a structure can be realized by distributed ledger solutions where the identity of the nodes are well-known. One algorithm might be that miner or validator node creates a private - public key pairs as identity where the public key is written into the blockchain but the private key is kept secret. If a piece of data is signed by the private key, it can be made sure that this piece of information was in fact validated by the protocol. The algorithm might be fine-tuned and further improved in a way that not only a leader node signs the piece of data, but many others as well, like in case of a quorum consensus or at a two phase Nakamoto consensus, like at Tendermint. The piece of information can be assigned by a timestamp as well, in the sense of validating the exact block where the information was signed. It can be realized as generating a new identity, new private public key by the validator nodes at each round only for the given round. 

Notes on Ethereum WASM

Ethereum WASM is on the horizon, providing a more stable, flexible and faster programming environment. However introducing the technology might bring a couple of unexpected results. The problem is that with the help of WASM there will be many other languages available for Ethereum programming, apart from Solidity. The real difficulty in Blockchain programming is however not the programming language knowledge, but actually the mindset. As Ethereum smart contracts store a huge amount of money on a public blockchain and actually the deployed code is pretty much immutable, developing such a code requires special considerations. Instead of Agile or DevOps methodologies, defensive programming, formal versification and correct by construction tools should be used. For those who has actually never taken part in mission critical system development, these methodologies are new. The result will be that many software developers with WASM compatible languages will start smart contract development, which will cause again a huge amount of buggy software and a lot of hacks on the public chain. That will result that the general perception of the chain security will be again pretty low.   

SLA with cryptoeconomical service guarantee

Service level agreements are important parts of every corporate infrastructure and for companies providing infrastructure or even software as a service products. Service level agreements provide at least a theoretical guarantee that if the service is not provided in a promised way, there can be something done. However to really do something if the SLA is not hold is difficult, starting a legal process might take years and cost a lot of money, finding a new provider and migrate existing services to the infrastructure of the new provider might again take month and can be pretty costly. 

A good solution can be however to introduce cryptoeconomical guarantees as insurance for a service, similarly as the Ethereum initiative Swap, Swear and Swindle does for off-chain computation and services. SLA parameters have to be formalized in an explicit and measurable way, and in case the service is not provided, the consumers of the service should be able technically, in a reliable way prove that the SLA was not hold. The service provider should make an insurance up to a certain amount of cryptocurrency that money is held online in a smart contract. Customers of the possible service providers might choose a provider not just based on services but on the fact how much it is cryptoeconomically secured, with other words how much cryptocurrency is locked as an insurance or security deposit in case there are problems with the service If a customer experiences problems with the SLA, an cryptogaphical proof can be generated for that, this proof can be validated by decentralized validators and in case the customer has right a certain amount of cryptocurrency can be transferred, up to the security deposit of the service provider. The whole process might run fully or  almost automatically, practically in minutes.     

Most limits of current technologies are actually limits of our neocortex

Different kinds of technologies are said to have limits, problems, drawbacks. However in some or most cases there are limits of the technology itself but limits of our own neocortex. As an example, according to the social scaling idea from Nick Szabo, the result of the institutional systems in the trust based services is the direct result of our neocortex is able to handle at most around 150 social connections. Probably, our love for the different hierarchical structures is the direct result that our neocortex is organized in a hierarchical way.   

Notes on efficient education and community building

Most education and community building strategies are based on two simple things:
1. Oxytocin - produced at collaboration, communication, team works ...
2. Dopamin - produced at achieving goals, getting positive feedback, reaching milestones or badges ...

Notes on community building

Taking part in a community building, the most important question is to decide if you are taking part building a true open Open Community or rather a Digital Apartheid. 

#Hashgraph

Creating a blockchain algorithm that can not fork

Creating a blockchain algorithm that can not fork is actually not so complicated. What we need to have is a mechanism to make sure that we know all of the miners or validators in the system. This might be a special transaction that can be initiated by a node that wants to join. This special transaction is mined or validated in a standard way and added to the list of  active miners or validators that can be stored in the ledger in part of the on-chain governance. 

After that the blockchain consensus algorithm has to have two rounds:

1. with the help of a Nakamoto consensus the next block can be found, however this block is still not applied to the state. The block is considered as a proposed block at first. 

2. The proposed block must be signed by more than 66% of the active nodes to be considered as valid and be applied to the state. Certainly, such a signing and voting process is not something that can necessarily efficiently realized on a global scale considering many active nodes. 

3. Last but not least, a deleting voting peers mechanism can be built in a garbage collection style. If a node do not have active vote for a long time, it can be considered as it has already left the active miner or validator nodes. 

The algorithm can guarantee the working mechanism without forks, as in case of a network partition there would not be enough votes for a given block. Certainly, there is no magic, in such a case, the network would simply stop working. We simply prefer consistency against availability in case of network partition, according to CAP tolerance.  

Notes on the strengths of the cryproteconomical guarantees

Cryptoeconomical guarantees are actually weaker than the pure cryptographical ones. Cryptoeconomical guarantee means that hacking the system is not profitable, meaning that more money will be lost than gained. As an example proof of steak is based on such a cryptoeconomical guarantee, that states that if I want to hack the system and it become well known you lost all of your stake. As it is a logical motivation that most of the people or rational actors behave economically rational, meaning that they tend to maximize the profit or benefit in some sense. However, the problem is that most of the economical guarantees exist only in the system itself based on assets and resources that are defined by the system itself. So, it is certainly if I try to hack the system in a proof of stake I will loose my stake, but perhaps I my economical rational profit maximization is not based hundred percent to the systems itself. As an example, if the hacking attempt will be well-known, the general trading value of the platform against like USD might fall, that means that I can make a profit from shorting and I might as well do profit even if I loose my stake. 

On the contrary cryptographical proofs use another scarce resource, which is usually computation. Simply put, most practical cryptographical algorithm assumes that breaking the algorithm is computational infeasible meaning that it would take millions of years even with the most advanced, state of the art computers. This is a kind of practically impossible guarantee which is much stronger  than a not profitable one. 

As a consequence, a cryptographical or computational guarantee is always stronger than a simple cryptoeconomical one, mostly because economical rationality can be interpreted only in the system but in general economical rationality is something more complex. 

Perhaps it is important to note though that proof of work is actually an economical guarantee not a cryptographical one, because the amount of computational power to break the consensus does depend on the competition of the miners. With other words, it depends on the amount of money invested to mining equipment.