Keys and addresses in a blockchain protocol

In a blockchain system, transactions usually form a {sender, recipient, amount} set which are signed by the private key of the sender to make sure the identity. However the exact implementation might vary depending on how the addresses are generated. In the easiest case, an address is simply the public key, consequently signing and verifying look as:

sign: data = sender, recipient, value    with key = private key of the sender

verify: data = sender, recipient, value    with key = sender (which is the public key of the sender)

However if more complicated cases, the public key of the sender is not stored directly, because the address is generated by an additional one way hash function of the public key. So at verifying the transaction, the public key of the sender has to be explicitly transferred or implied somehow:

sign: data = sender, recipient, value    with key = private key of the sender

verify: data = sender, recipient, value    with key = private key of the sender, which is however not the same as the address of the sender. 

Blockchain immutability is a cryptoeconomical guarantee

Blockchain is said to be immutable, meaning that a give transaction can not be changed if it is already in the blockchain, because the whole structure is secured by crypthograhical hashes, that can not really be broken. However it is important to note that the immutability is not necessarily a pure cryptographical guarantee, it might depend on cryptoeconomical perspectives as well. Like in a proof of work system, a long range attack, meaning building up the whole blockchain from the genesis block, or from the block of the given transaction cost a lot of computational power but not impossible. Especially if we can take into account that the mining difficult might not always increase, but it might decrease as well. Similarly in a proof of stake scheme a long range attack cost a lot of money, however that is not a cryptographical guarantee. 

As a consequence blockchain immutability is not necessarily a cryptographical guarantee but it might be a cryptoeconomial one, depending on the used consensus algorithm. So instead of saying that  it  is computational impractical to change a recorded transaction, we claim something weaker, like it cryptoeconomically impractical (or not profitable) to change a recorded transaction.  

Tools for decentralized requirement engineering

Requirement engineering in an enterprise context can be a pretty tough problem, especially at discussing with ever participants and stake and stockholder of the project and achieving a common decision. It will be even more difficult in the context of a consortium blockchain solution as not only a participants of one but several companies should be taken into account. Achieving a common decision in such a situation might be a nightmare. What we would need are tools for the decentralized requirement and process engineering. Like a common dashboard on the process or requirements must be presented with several possible governance algorithms where the participants can vote or modify the process or the requirements based on different interest. Based on the outcome of the decentralized process engineering, the final blockchain system can be designed. The requirement or process engineering can be itself supported by blockhain and of course everything that has anythin to do with on-chain governance will help a lot. 

Bitcoin difficulty and on-chain governance

In the bitcoin protocol there is a part which automatically adjust difficulty in a way that the block time is always fine-tuned to 10 minutes blocktime. If the current rate of blocks is faster than 10 minutes, than the difficulty is increased, if it is slower, the difficulty is decreased. Similar ideas can be found in other blockhain solutions as well, like Ethereum or Monero. This mechanism can be thought as a kind of a on-chain governance method where practically the miners with computation as a scarce resource vote for the change to take place or not. 

Blockchain advanced anonymity techniques

 

Original implementations and design of a Blockchain is unfortunately far from being perfect. The reason for that is that in the consensus mechanism every node has to be able to validate all of the transactions which can be easily realized only in a pseudonym fashion. There are however several initiatives to increase the privacy, among the others, the most important ones are the followings:

1. Zero-Knowledge Proofs: A prover proves knowledge of a secret without revealing it. There is an initiative for example to build zero knowledge proof into the Ethereum platform. 

2. Stealth Addresses:  Using one-time addresses for sending/receiving transactions for an account. It is used for example in Monero. 

3. Ring Signatures:Type of digital signatures that lets any member of the group sign, but no one can tell which one signed. It is used in Monero for example.

4. CoinJoin: Transactions from several senders to several recipients are mixed together to hide who is paying whom. There are services for that even at Bitcoin.

5. Confidential Transactions: Uses homomorphic encryption to allow transactions to be processed while encrypted. Proves transaction value is in a range of values to prove that overspending did not occur.

Some types of these techniques, like Sealth Address, Ring Signature or CoinJoin can rather be used only with cryptocurrencies, as other types like Zero Knowledge Proofs or Confidential Transactions, are to be used both in cryptocurrencies and in smart contract based systems. 

Blockchain consensus and scarcity

Blockchain consensus is based always on a scarce resource, like at proof of work this is the computing power, at proof of stake this resource is some kind of a token that has a limited supply and kind of monetary value, at proof of authority or byzantine fault tolerance this resource is kind of a right given by a decentralized authority for voting. The reason for the need of the scarce resource is that the sybil attack, like replicating a node a couple of million times on a cloud environment, can not work because participating on the consensus depends on the scarce resource and not on the number of replicated nodes. 

Block identification in a multi-hash blockchain

In a classical blockchain platform, each block is identified by a the hash of the block which contains all of the possible information of the transaction, nonce, difficult, previous block hash and so on. From a practical point of view it works as an id of the block. In a multi-hash blockchain, the situation is however a little bit more complicated as there are at least two different hashes of the block. They are certainly, not absolutely independent from each other, as they contain the same data and transactions, however the resulted hash values seem to be totally independent from each other because of the characteristics of the cryptographic hashes. There might be several ideas to identify the blocks:

- one option might be to simply use the two hashes. However as soon there is not just a pair of hashes but a complex hashmatrix, we might as well handle several docents of hash values, which makes the process relative less user-friendly. 

- we might as well use something which is calculated based on the consistent information of the hashes, but itself directly is not contained in the chain. One idea would be the hash of all of the hash pointers. 

- Another idea might be to use something which is "bellow" the hash pointers, like the hash of all data. It might provide the possibility to easily check if a certain data is available in the chain or not. Certainly, the disadvantage is that it might provide an extra attack vector for tricky hackers.  

Security of the blockchain as authenticated data structure

Blockchain is actually something as an authenticated data structure, which is a special linked list, where to create some of the hash pointers require a kind of a work to do or a kind of a monetary stake to risk. It means that we can consider the security of a given transaction which is mined in a block. This security will increase as the further blocks are minded on the top of the chain. The security is dependent on the exact consensus mechanism, but will increase somehow as follows:

Actually in a standard forking attempt, it is considered that a given transaction is secure if more than 6 blocks are mined on the top of the chain at Bitcoin and like 12-15 at the case of Ethereum. However if we an old transaction, than further added blocks increase the security further. It is certainly required at an UTXO style system, because old unspent transactions should also payed into account, however it is questionable if we really need it if we use an account based system like Ethereum.  

Solidity Pattern and Practices: CRUD (Create Read Update Delete) on asset

So let we imagine the situation that want to create some basic asset on the ethereum blockchain that mimics the CRUD (Create Read Update Delete) operations, possible considering different roles and rights as well for the different operations. We could use something similar. For the first run we can defined an enumeration giving the first set of basic access controls and some kind of an internal data structure that we want to modify:

contract CRUDAsset {

  enum RightsEnum{
      Create,
      Read,
      Update,
      Delete,
      Admin
  } 
  
  struct DataStruct {
      uint data;
  }

  DataStruct data;

As a second step we can define a possible right configuration for each address and give modifiers that check the existence of these modifiers and of course a constructor that gives admin right for the first account.  

  mapping(address => RightsEnum) rights;
  
  constructor(){
      rights[msg.sender] = RightsEnum.Admin;
  }
  
  modifier CanCreate {
      require(rights[msg.sender] == RightsEnum.Create);
      _;
  }
  
  modifier CanRead {
      require(rights[msg.sender] == RightsEnum.Read);
      _;
  }
  
  modifier CanUpdate {
      require(rights[msg.sender] == RightsEnum.Update);
      _;
  }

  modifier CanDelete {
      require(rights[msg.sender] == RightsEnum.Delete);
      _;
  }

  modifier IsAdmin {
      require(rights[msg.sender] == RightsEnum.Admin);
      _;
  }

After this step we can define the CRUD (Create, Read, Update, Delete) operations with the given access rights.  

  function Create(uint _initialData) CanCreate {
      data = DataStruct(_initialData);
  }

  function Read() CanRead returns (uint) {
      return data.data;
  }

  function Update(uint _newData) CanUpdate {
      data.data = _newData;
  }
  
  function Delete(uint _newData) CanDelete {
      data.data = 0;
  }

  function AddRight(address _to, uint _right) IsAdmin {
      rights[msg.sender] = RightsEnum(_right);
  }
}

Certainly, the structure can be refined in several ways: 

- It is not a general schema for any kind of a data, it is valid only for the one specified DataStruct structure. It is even difficult to extend it to general data structures as the basic elements has to be defined at the moment in the function signatures. 

- Read actually means only reading out from the contract or from the user interface. The variable is not secret if someone has direct access to a blockchain node. The situation can be fine-tuned with encryption or with zkSNARKs. 

- The model has the one address -> one access model. It can be extended on a long run to a one address - multiply access right version. 

Solidity Tips and Tricks - decentralized maintenance

In a blockchain system, you might sometimes have the problem, that there should some kind of a maintenance job that should be running regularly. For such a problems, you usually implement something as a maintenance or timer job in centralized systems. However considering a fully decentralized system it is pretty much unpractical. What might be a good direction is to create a special decentralized role for maintenance in a way that this role will be rewarded somehow for doing the maintenance. The idea is similar to the idea of the miners. A miner maintain the state of the blockchain and for that activity they are rewarded by the transaction fees and the newly generated coins. The idea can be repeated however, there might be further roles doing kind of a system maintenance jobs for a certain  monetary reward. A very simple solidity code for that can be seen in the followings:

contract DecentralizedOperation {

    mapping(address => uint) balanceOpReward;

    

    function Maintainance() {

        // do maintainance

        balanceOpReward[msg.sender]++;

    }

}