Wallet functionality in Blockchain full nodes

Most blockchain nodes contain a kind of a wallet functionality if they provide some kind of a functionalities for the end-users as well. This is actually not a coincident, both in account/balance and UTXO based systems, private keys self are not stored in the blockchain. As a consequence, for creating a new account which is practically a public private key pairs we need a local wallet functionality. Locally created addresses appear in the blockchain only if someone sends money for that address in an UTXO based system or if that account is explicitly added to the system in an account balance based blockchain. As a consequence a wallet has the following functionalities: 

- creating accounts: generating private public keys

- managing already created accounts that are still not added to the blockchain

- managing accounts already added to the blockchain, calculating balance, managing keys ...

Adding an account to the blockchain in a balance based system

In an account/balance based blockchain solution not only the transactions but the accounts and balances are stored in the blocks as states. It is an interesting question how such a system can be implemented. As the state is built up practically by the set of <account,balance> tuples a new account should be somehow added to the state. There might be the following possibilities for that:

- explicit transaction for adding an account to the state.

- implicit transaction for adding an account to the state, with a logic, like: if account not exist in state than add with the initial data.

- some kind of a tricky hash structure that indirectly stores or the possible accounts, but not store them directly. Certainly, it is questionable if such a thing can be realized with the structure consideration of the blockchain. 

A further question arises how such an account should be deleted from the state. A simple zero initialization is surely not enough as we are not sure if that is really an intention to delete. The clearest way is to have the possibility for something as an explicit delete transaction that deletes the given account from the state. 

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.