How to implement a Blockchain from scratch - syncing accounts between state and wallet

In an account balance based blockchain system, there are accounts both in the blockchain state and in the wallet as well. It is important to understand the life cycle and syncronization between these elements:

- The accounts in the wallet should represent only a copy of the accounts of the state.

- Extended information can be stored art the accounts of the wallet, as an example the private keys for making signature simpler. 

- The accounts of the state should contain only public keys or addresses derived from public keys, not private key should be stored in the account of the chain. 

- After every new block, the wallet has to be synchronized. It is an open question how the synchronization should be carried out with the fork resolution strategy. There might be different strategies, like showing always the values of the top block of the actual state or waiting for a certain number of confirmations to avoid forks. 

- If a new transaction is initiated, it might refer to accounts that are still not in the state, only the public private keys or address were generated and they are only stored in the wallet. 

- At a currency transfer transaction the from account has to be in the state with a big enough fund and with a consistent nonce. 

- At a currency transfer transaction the to account should not necessarily be in the state. It can be added at the mining with the amount of money that is transferred to. It is important that the to account must be compatible with the from account if we consider a multi-asset scenario.

- There must be a couple of genesis accounts and or coinbase transactions for each cryptoasset, for the initial distribution of the monetary supply. The exact implementation depends on the issuance of the cryptoasset. For creating a genesis or coinbase of a new crptoasset, a new validation rule, perhaps a brand new transaction type has to be introduced.   

- At a data setting transaction, the initial account must not necessarily exist, it can be added anytime if there is a valid signature related to the address of the account. 

  

Everything You Need to Know About Cryptocurrency Regulation (Right Now)

Guest blog from UpCounsel

Written by Gary Ross

(This article was originally published on UpCounsel.)

The meteoric rise of cryptocurrencies has taken the world by storm. Innovators, investors, users, and governments are scrambling to wrap their heads around cryptocurrencies and the blockchain technology that they rely upon. The emergence of a new market and business model has created great opportunities for participants, but it also carries significant risk.

Cryptocurrencies present an inherently unique challenge to governments because of their new technology, cross-jurisdictional nature, and frequent lack of transparency. Governments are struggling to develop new ways to regulate cryptocurrencies, adapt existing regulations, and identify fraudulent schemes. Cryptocurrencies and their regulations are evolving before our eyes, and this article will provide a brief background on cryptocurrencies and an overview of where cryptocurrency regulations currently stand.

What are cryptocurrencies?

Cryptocurrency is, by any other name, a currency—a medium of exchange used to purchase goods and services. Or, as some have suggested, cryptocurrency is a “peer-to-peer version of electronic cash.” However, this currency has two qualities that distinguish it from traditional bills and coins.

First, cryptocurrency is a virtual currency that is created through cryptography (i.e. coding) and developed by mathematical formulas through a process called hashing. Second, unlike traditional bills and coins that are printed and minted by governments around the world, cryptocurrency is not tied to any one government, and thus is not secured by any government entity. The fact that cryptocurrencies are not secured by a government authority has led to concerns from critics that this is the second coming of Tulipmania, because we are ascribing value to an otherwise valueless item. However, the potential for cryptocurrencies as a medium of exchange remains enormous.

What is blockchain?

Blockchain is the technology at the heart of most cryptocurrencies, and explaining the technology in detail would require a blog post of its own. What is important to know is that blockchain is a record of peer-to-peer transactions categorized into blocks on a distributed ledger. Despite the obtuse terminology, blockchain functions similarly to a local bank authorizing and recording a transaction, but instead of only one party holding the entire ledger book, the transactions are recorded communally by member nodes, with each node being a computer in a peer-to-peer distributed network.

The blockchain can confirm a transaction within minutes, removing errors that exist when trying to reconcile and audit separate ledgers and transactions. Whenever a transaction takes place, the miners on the blockchain develop a new hash and digital signature to update the ledger and create a new “block.” This block, or recorded transaction, is time-stamped and encrypted and will remain on the blockchain for life.

Regulation in the US – Utility Tokens v. Investment Tokens

In the United States, there has been no federal regulation of cryptocurrencies. Instead, cryptocurrencies are often grouped into two non-binding categories: (1) investment tokens that fall under the purview of already existing U.S. securities laws like the Securities Act of 1933 and the Securities Exchange Act of 1934, and (2) utility tokens, which remain largely unregulated (for now).

Security Tokens

Whether the tokens being offered in connection with a particular cryptocurrency are security tokens is decided on a case-by-case basis that even experienced securities lawyers can disagree upon. Tokens are usually analyzed under the four-part Howey Test below to see if the token is in fact a security. Securities must meet the following criteria:

1. An ​investment of money

2. in a ​common enterprise

3. with an ​expectation of profits

4. predominantly from the efforts of others

Each characteristic of the token is analyzed against this framework to see if the cryptocurrency is in reality functioning as a new-age security. If it is, then regulators treat it as such, and cryptocurrencies must then be registered and handled with all of the same disclosures and precautions as any other security sold in the United States or to U.S. investors.

Utility Tokens

Cryptocurrencies can also be categorized as non-security utility tokens. These tokens purport to offer intrinsic utility and value, and are typically instrumental in powering the blockchain technology. These tokens function more like commodities than securities, and while they may act like currency in a fully functional network, they also have other values.
However, having a utility token with a properly formed and functioning network does not preclude said token from being labeled a security by the SEC. In In the Matter of Munchee, Inc., a purported utility token with a non-functioning network was labeled a security by the SEC. While labeling a token without a functioning network as a security – as it has no present utility – is not unexpected, the SEC also concluded that: “even if [Munchee] tokens had a practical use at the time of the offering, it would not preclude the token from being a security.”
After analyzing the Munchee Tokens under the Howey test, the SEC concluded that they were investment contracts because purchasers of the tokens had an expectation of profits predominantly from the efforts of Munchee and its staff. The SEC further concluded that Munchee had primed such expectations through its marketing efforts.
While this new case does not eliminate the distinction between utility and security tokens, it does caution that, when deciding whether a given token is a security, the SEC will look beyond utility at the character of the instrument, and base their conclusion based on the terms of the offer, the plan of distribution, and the economic inducements held out by the token issuer.

State Regulation

So far only the state of New York has issued any kind of regulation specifically regarding cryptocurrencies: the BitLicense. The BitLicense is New York’s attempt to control cryptocurrencies within its borders by requiring cryptocurrency businesses to register and comply with several different disclosure and financial obligations. The regulation has been divisive, and many businesses have rallied against its high costs. While a few companies have applied for and received the license, most other companies have simply left the state or stopped offering services to its residents.

Regulation Abroad – The Ever-Shifting Jurisdictional Question

The United States is not the only country grappling with how best to regulate cryptocurrencies. Many cryptocurrency businesses face daunting questions regarding in which jurisdictions to form and to do business in. In the end, the question is quite difficult and fact-specific, requiring communication between legal counsel in different jurisdictions and taking into account nebulous and piecemeal country-by-country regulations. It is impossible to do a detailed analysis without knowing how a country’s existing securities laws, financial regulations, and banking regulations will operate (or will be adapted to operate) with cryptocurrencies. The fact that cryptocurrency-specific regulations are still developing does little to add clarity, and makes the analysis even more challenging. Yet a few global trends are noticeable:

Suspending Cryptocurrencies

Some notable countries, like China, and South Korea, have suspended cryptocurrencies. These countries have cited the risk of fraud and the lack of adequate oversight in suspending cryptocurrencies and their exchanges, forcing cryptocurrency companies and exchanges to relocate.

Regulating Cryptocurrencies

Other countries, like Japan and Australia, have adopted disclosure and regulatory measures, or have companies register with the applicable government authority. Several countries have also tried to implement disclosure or registration regulatory regimes when it comes to cryptocurrencies, but such regimes are cumbersome and expensive to fledgling companies.

Cryptocurrencies as Commodities

On the other hand, Switzerland and Singapore, two of the countries at the forefront of the cryptocurrency market, have simply stated that cryptocurrencies are assets, not currency and that they will treat them as such under existing regulations.

Conclusion

Ultimately, cryptocurrency regulation remains in its infancy. Piecemeal regulation has already begun around the world as governments enact new regulations to control and legitimize cryptocurrencies, fold cryptocurrencies into existing regulations, or ban them outright. These splintered attempts at controlling a global phenomenon will keep the cryptocurrency market volatile, and pose a challenge to innovators, investors, and users. They will continue to work in the cryptocurrency space while pushing for legislation and regulation that will remove ambiguity and legitimize cryptocurrencies. At the same time, they must grapple with the possibility that new regulations may be confusing, detrimental, or have negative inadvertent effects.

Blockchain strategy and bootstrapping the ecosystem for developers

With the appearance of the newer and newer blockchain platforms, every company tries to position  and bootstrap the platform differently regarding the developer community and attract more and more developers the work with the platform. Strategies might vary as:

- creating a brand new platform with a brand new language: the best example for that is solidity, as it was one of the first language for blockchain development it made sense to invent a brand new language. Similar attempts were initiated by Vyper or by the modelling language of Hyperledger Fabric Composer. 

- supporting a well-known language: many platforms tries to use a well-known language which was previously widely used by programmers, like Java or Javascript, and attract as much developers from the given language as possible. Similar strategy is the choice of Java for Hashgraph, or the Java and Javascript for Hyperledger Fabric.

- last but not least, there are platforms that support multiply programming languages like Tendermint or Babel, trying indirectly attract everybody who is a developer throughout the world.   

The strategy can be however extended. As the aim should not be be of any such a platform to attract as much developer as possible, but as much application builders or applications as possible. In this sense strategical direction can be to attract business users instead of developers and provide no-cost or low-cost application development environments. Another idea might be to provide an interface or possibility to integrate different exiting business applications, or use directly a domain specific languages for modelling businesses integrated with the blockchain platform, like different BPMN notations. 

How to implement a Blockchain from scratch - gossip protocol

Blockchain protocols have several different ways of communication, there are gossip and non-gossip based ones. The beginning of the network communication is usually a non-blockchain based one, a peer connects to several neighboring peers, checks versions of the peers and queries further peer information if it is required. Similarly, synchronizing the blockchain is not a gossip protocol either: the peer queries the neighbors for the latest block number and based on an inventory query it will synchronize the whole blockchain. Blocks and transactions are propagated with the help of a gossip protocol. The logic is something similar: 

- If the node initiates a new valid transaction, the transaction is added to the transaction pool and propagated to all neighbouring peers. 

- If a node receives a transaction, first the validity of the transaction has to be validated. If the transaction is valid, it has to be checked if the transaction is already somewhere mined in the blockchain or in the transaction pool. If so nothing has to be done. If not, the transaction has to be added to the transaction pool and the transaction has to be propagated to the connecting peers except from the one from that we got it. 

- If a miner mined a new block, the block has to be propagated to the network, and the local wallet has be updated based on the new block information. 

- If a node gets a block on the network, first the validity of the block has to be checked. It might be a little bit difficult, because it might still not in the blockchain. Therefore there should be an explicite set containing stale blocks that still can be not added to the blockchain. A new block is valid if it can be added directly to the blockchain, or there is already a stale block in the pool and the two blocks can be added to the blockchain. If it can not be added to the chain, it should be saved in the stale blocks pool. If the block is already in the blockchain or in the stale blocks pool, there should not be propagated further. Otherwise the block must be propagated to the neighboring peers. 

To avoid network overload, it is possible to use only the block and transaction id-s in the gossip, flooding process and getting the content of the data only if it is necessary.  

the different the roles of proof of work

Proof of work has several different roles in a blockchain protocol. On the one hand, it guarantees that old values of the chain can not be hacked, they would be needed to recalculate the whole blockchain starting from the modified block. On the other hand it is essential to the fork resolution strategy, the longest chain wins actually means that the chain with the most cummulated proof or work wins. These two roles in a Bitcoin or Ethereum protocol combined into one, however they not necessarily must be always combined. Cummulated proof of work could be actually separated from the consitency of the blockchain, as there might be requirements where the cryptoeconomical security of a given transaction should not be increased without end but might be limited after a high enough number.  

Opening business processes via triple entry accounting and blockchain

Blockchain and triple entry accounting makes it possible to create business processes that are easier to audit or verify. Let we imagine for example the following use-case. A company creates a balance about the activities of the company at the end of the year, and based on that result pays dividend to the stock holders. However accounting only at the end of the year might be not so reliable and offers a lot of place for misuse. However, the process can be more transparent if we register the result of the company on the blockchain on a daily basis, like the costs and revenue, or some relevant business related information. Although there is the possibility for misuse and gaming in such a situation as well, however it is much more difficult. 

Certainly, no company would like that such business related information is visible on the blockchain on a daily basis for the competitors. However what might be done is to use a kind of a proof of existence system and for example registering the hash of the relevant information on the blockchain on a daily basis. At the end of the years, daily information related to the hashes can be published which makes the yearly performance of the company more reliable. Another solution might be to use some kind of a more advance cryptographic scheme, like zero knowledge proofs or functional encryption.   

Notes on on-chain decentralized internal asset exchanges

Designing a blockchain solutions from scratch provides the possibility to implement certain special functionalities into the blockchain. One such a functionality can be an internal exchange that makes possible to exchange different internal or even external assets. For an internal asset exchange to be the fundamental part of a blockchain protocol, we need the following elements:

- an asset - account based system is more practical than an UTXO based one. 

- each account has to be associated with an asset type that can be transferred or traded. 

- for the sake of simplicity, one account should contain only one type of asset, so account type should be decided at the initialization and it should be immutable. 

- transfer transaction should be extended, similarly to a standard case transfer transaction should be signed by the private key of the account from which we would like to transfer the asset. However, the target account must have the same asset type as the from account. 

- there might be some further consideration if certain asset types have different monetary policies, like different digits, different monetary supply, and so on. 

- there should be a special trading transaction which in a simplest case offers a certain amount asset and requires a certain amount of other asset. There might be some further parameter, like time-frame of the transaction in which it can be executed, upper or lower "price" limit of the transactions. The trade transaction is signed by the private key of the initiating account. 

- in mining not only the transfer transactions are executed but the different trading transactions are paired. If a valid pair is found, they are put into the block and the effect of the two transactions are applied to the state. So in this sense mining here also means finding a set of paired trade transactions.  

How to implement a Blockchain from scratch - event bus

Key component of the every blockchain architecture must be a reliable event bus. There are many parallel actors working with the data of a node, like 

- peers gossiping and requesting information, like new transactions, or new blocks

- wallets initiating transactions

- miners or validators working directly or indirectly with a node

- blockchain explorers requesting important data regularly

- and of course an advanced logging system writing everything to a local log and supporting both standard and debug mode is also required. 

For this reason, it is practical that every node implements an event bus with the funcionalities: 

- different actors can push different pieces of information on the bus, with the type of information and the severity of the information or error. 

- different actors can subscribe for different pieces of information, as an example, a logger would write everything into a file, a wallet would be interested on events if the blockchain gets synchronized, if the initiated transaction gets mined or validated, if the balance of a supervised account changes and so on. Similarly, a blockchain explorer interested if there is a new transaction which is being gossiped into the system, if there is a new but still not validated block, if there is a new validated block and so on. 

Even some part of the standard protocol might work totally asynchronous from each other realizing the central communication protocol via an internal event bus of the node.    

On the accounts of a account balances based blockchain system

Accounts of an account-balance based blockchain system are practically storage spaces that access is controlled by a public - private key ownership or identity proof and validated by the nodes. In a simplest case an account stores the balance of a use, a signature with the private key provides kind of a proof of identity, that you are allowed to access to the given account. It is important to note that in a transfer transaction, there are two balances that are validated differently: 

- the from balance must be checked if it matches with the signature of the private key of the account and the balance must be bigger than the amount of cryptocurrency to be transferred. 

- the to account must be compatible however with much less rules. Practically, it must not eve exist, it can be added to the chain on the fly. 

Ethereum extends this simple model to two different kinds of accounts: externally owned accounts and smart contract accounts. As externally owned accounts can practically initiate transactions to smart contracts, with prooved ownership of private public key information, smart contracts only react for external events. However the model can be even further extended. In a certain blockchain system, there can be: 

- Any kind of different account, with different state storage and validation rules, like accounts for miners, validators, special roles executing optimizations...

Syncing Blockchain from a certain block or time

At blockchain synchronization one of the biggest problem is that the full blockchain has to be synchronized and validated from the genesis block. Supposing we have an UTXO based system, it is actually necessary, because there might be UTXO-s which are at the beginning of the chain, but despite they can be spent. We could however consider with an account-balance based system not to download and validate the whole blockhchain just like the last thousand blocks, as the correct state is contained at the last state as well all the other blocks are related only a a consistency and security guarantee. Such an algorithm might have raise the following issues:

- Depending on the consensus mechanism downloading the last thousand block can be as much secure as downloading everything from the genesis block. In proof of work a long range attack from a thousands block in the past is as much impossible as doing a long range attack from the beginning. Similar might be true for proof of stake and other consensus algorithms as well. 

-  The real challenge is however to get the quasi genesis block in a reliable way. Certainly getting thousands blocks that are fake are not necessarily simple, but an attacker could simply send an older version of the chain fragment, let we call it as a replay blockchain fragment attack.      

- To prevent a replay blockchain fragment attack, we can introduce a the block numbers in the block headers. So, first step of the P2P algorithm would be to query the block heights, and bases on the block heights, the blocks with the exact numbers can be queried.

- However, there might be one more attack vector. Even if we have block identity information in the block headers, and attacker might try to build up a blokchcain segment in the future, knowing simply the block id-s and broadcast this fake segment as soon the blocks from the certain id are queried. Let we call this attack as alternative future blockchain fragement attack. There is no known good to implement a chain resolution strategy that can efficiently distinguish between the valid chain and an alternative future.  

Notes on blockchain system state

The state of the blockchain can be different in different platforms and representations. In an UTXO bases system, the system state is indirectly represented by the outputs of the transactions. In an account - balance based system, each account contains an internal variable storing the balance and the account can only be changed if the owner signs a transaction with the private key. The model can be extended to contain variables and other elements in the state, just like with Ethereum, where the different state variables can be changed under different validation conditions. Further improvements can be imagined however, both the state and the validation can be hundred percent customized just like at Tendermint and a couple of similar blockchain systems. There might be a separation between standard and system blockchain state, giving an opportunity to on-chain governance. We might as well imagine that the blockchain state contains full scale objects, including properties and functions as well where the object state can be changed only via the functions that has to be signed by the private key related either to the public key of the object or the public key of the functions.  

Enterprise blockchains and identity management

Enterprise blockhcain solutions has usually totally different directions regarding identity management and user authentication. They usually integrate some kind of cloud or more decentralized identity management system, efficiently authenticating and personalizing every transaction and access to the system. Examples are Azure Blockchain as a Service with the help of Active Directory Services or Hyperledger Fabric Composer with the help of Membership Service. It is totally different from the open public world however, where you generate a public private key pair and practically the private key represents the identity. However even in enterprise scenarios, the two approaches should be combined. One part of the service might be authenticated with the help of classical centralized identity services, however part of the application could follow classical antonym authentication methods with the help of private - public keys. The authentication situation might be an analogy to the a classical portal system, where you can reach some of the content publicly on the internet as other content and services are protected with classical identity management systems. 

blockid in a multi-hash blockchain system

In a multihash blockchain system, individual blocks do not have one hash identity but several ones, at least one pair for each hash link. This guarantees the consistency of the blocks. Despite if one wants to  download or refer to a block, it is much more practical if we have one common id, that can be refereed either at the communication protocol or from the blockchain explorers. Such an id can be for example the hash of all of the exiting hash links and hash pointers. Certainly, it is an open question if such a construct open a new attack vector or vulnerability, because the block hash directly is not contained in the hash list of the blockchain. 

Blockchain and cryptographical rolling hash

Blockchain solutions has one of the key advantage that they are pretty much hacking resistant, because of the chain of blocks and hashes that going back up to the genesis block. However, most of the applications do not necessarily require such a huge security guarantee, it is probably enough if data can not be hacked and consistent considering the last couple of months or years. On the other hand, there can be the requirement to delete from a blockchain solution or has the possibility to forget or modify data. On solution might be to design a blockshain platform where data is not hashed back to the genesis block, but only the last couple of like thousands of blocks are considered. Certainly, it is a question how such algorithm can be realized in a hacking resistant way. One solution might be to try to use instead of cryptographic hashes, a kind of cryptographical rolling hashes, where only a certain number of past values are considered as input.  

How to implement a Blockchain from scratch - smart contract simplified

In a simple account/ balance/ state based blokchain system implementing smart contracts is pretty straightforward. Accounts represent for the first run not necessarily just balance but a kind of a general data as well that can be modified by the smart contracts. In order to create smart contracts, you should define the language or smart contract programming environment itself and the effect that a smart contract can result in the state. Certainly one way of doing it is to define a virtual machine which guarantees that the smart contract is executed exactly the same way on every peer. However we might as well consider an exiting virtual machine as well, like the java virtual machine and limit somehow the effects of the program. As an example a simple smart contract could: 

- read some of the state information of the blockchain manifested by accounts data and balances. This state information is the previous block on which we want to mine our contract. 

- having some computation on top.

- changing the data value of a certain account. 

- storing the smart contract code somehow as data or string, like with the help of serialization

- creating a special transaction containing the smart contract as data with the sign of the account that you want to modify, indicated indirectly the owner of the account allows the data to be changed. 

At mining process:

- The signature of the smart contract transaction has to be checked. 

- It has to be made sure that only the effected accounts are modified.

- The code has to be run and the new data value must be calculated. 

- It has to be made sure that the smart contract does not cause infinite loop, one way of doing it is to avoid general loops, or to terminate the contract after a certain number of iteration resulting the transaction as invalid. Certainly another way can be built in as well, like with the help of a cryptoeconomical mechanism longer smart contract runtime can disincentivized, just like as with Ethereum.

-  The new value or values have to be applied.

- The block must contain the valid transaction and the new valid state, which is the new value of the computed accounts. 

At validation process, practically the same steps have to be repeated, without the last one, which is putting the transaction and state to a new block and doing proof of work calculation or voting of a byzantian consensus mechanism:

- The signature of the smart contract transaction has to be checked. 

- It has to be made sure that only the effected accounts are modified.

- The code has to be run and the new data value must be calculated.

- The calculation must have finite time. 

- It has to be checked if the new values of the state of the given are the calculated values based on the values of the previous block.

  

The wallet functionality has to be extended:
- to have the possibility to write or integrate smart contracts.
- to transform the programs into data, like with the help of serialization.
- to create transactions based on the smart contract.
- to sign them.
- to broadcast them on the network. 

How to implement a Blockchain from scratch - extended wrapper classes

At designing at implementing a blockchain system from scratch, there might be some contradictory design perspectives: on the one hand elements of the blockchain that are stored or transported on the network must require as less storage as possible, resulting in lower bandwidth or data storage requirements. On the other hand for efficient processing, some further information is usually required. Examples are: 

- Blocks in a basic scenario should store the difficulty, the nonce and the a hash value of the these values values together with the merkle roots of the transactions and state and the previous block hash as well. 

- Blocks in an extended scenario might contain explicitly a link for the previous block, for the further, some information if it is an orphans block or on the block height.

- Accounts in a basic scenario should contain an address of an account, which is usually a public key, and some kind of a change request, like transferring money, or changing a value. On top, certainly a nonce value.

- Accounts in an advanced scenario are related rather to the accounts of a certain wallet, so they might contain explicitly the private key and meta-information if the account is synchronized with the blockchain, or still not available in the blockchain.

There might be a similar consideration for other elements of the blockchain as well, like Block Headers, Transactions or Peers. Practically every object that is moved on the network can be considered as implemented as a basic version containing only the relevant data, and as an extended version containing all the computational relevant data.

The new divide of the information society

There will be a new divine in the information society between people producing information and people consuming information. As information can be simpler and more automatically produced every day, like with the help of massive online courses, chat bots, and different online platforms, it will be more and more information produced by less and less people.

Services will become more and more automated, meaning that more customer service will be carried out by bots or robots, resulting a cost factor saving in the employees and enabling fully automated decentralized companies. As an average customer it will be more and more complicated to fight through the bureaucracy of  bots and robots and get to a "living" person.

Notes on fork resolving policy

In bitcoin network, there is a general rule, always the longest chain should be accepted as a valid on. However this is just one implementation of a so called fork resolving strategy which might be extended and generalized on a long run. Such extensions might include: 

- instead of just chains, considering the whole weighted structure of the possible forks, like in Ethereum taking also uncle or omar blocks into account.

- in a permissioned chain, blocks might be prioritized and weighted based on the fact who signed them.

- in an attempt to avoid selfish mining, the blocks might be weighted with the creation time.

Further implementation and algorithms might be also possible, it is only important to note that fork resolving strategy as taking always the longest chain is only one possible implementation.  

How to implement a Blockchain from scratch - network protocols

At creating a blockchain solution from scratch, one of the most important part is to design a set of network protocols. It is important to note that these protocols are on the application level, under the hood they might be realized by simple socket sending on a TCP, something more abstract RPC or JSON-RPC, or even with onion routing. At any case, the following protocols should be considered:

0. Get client version: connecting to a known peer and getting the version of that peer. It prevents the usage of incompatible peers, that might be highly important especially if there are updates of the code regularly.

1. Update peer information: A brand new peers is usually started with a couple of preconfigured nodes further peer information. These peer information are queried for the further known peers until the number of known peers reach a certain limit (like 15 in Bitcoin by default). The peers may go offline and come back online again, therefore the active peers have to be checked regularly if they are still alive, if not different strategies can be implemented, like:
- deleting the inactive peer from the cached peer list.
- waiting for a certain time if the peer will be online again.
- querying all the still active node to get more peers that are hopefully active.
- or a combination of the previous strategies.

2. Syncronizing the blocks and states: As a first step of using the blockchin, the blockchain must be more or less up to date with the rest of the world. As a first step, the node can connect with all of the peers and ask the size of the blockchain. Based on that information, it knows exactly if the blockchain needs to be synchronized or not. As a second step a

3. Propagating transactions and propagating blocks: if new transactions or blocks arrive, they must be registered locally and further communicated possibly as fast as possible to all of the connecting peers in the form of a gossip protocol. If it is a transaction, it must be added to the local transaction pool, if it is a block it must be added to the possible top headers of the blockchain.  It is especially critical with the new blocks as the winner of the mining competition depends on the speed of the propagation. This phase should be available just after the blockhcain has already reached at least a quasi synchronized status. It is however an interesting general question how the propagating mechanism might stop, without effectively over flooding the network. One way might be to implement something as a finite hop system, in which a given information is propagated only at a given time. Another idea might be to implement regularly handshakes where peers exchange information on relevant transactions and blocks first before transporting them. 

In all of the communication protocols, it is always questionable, if we consider a kind of a push or pull protocol. In both protocols, the design direction should be to transfer as less amount of data as possible, and only if it is necessary. As a consequence, most protocols should transfer the inventory first, meaning the hash values of blocks and transactions. After that the nodes should be able to download the content of the hash values on-demand. 

Double spending in account - balanced based systems

Double spending in an UTXO based system is relative simple. Each transaction output can be considered as a "coin" that can be spent only as a whole and only by one transaction. It practically means that applying two transactions in a round for an unspent transaction means a kind of a double spending. The situation gets a little bit complicated if we consider an account / balance based system. One implementation of such a system is that there is a nonce both at the account and at the transactions as well: if the transaction nonce is by one bigger than the account nonce, implies that the transaction can be applied to the account. Otherwise we might as well have a replay attack. Despite of the logic it remains questionable how such a logic can be implemented. The versions are the following:

- After each transaction, the nonce is incremented by right away one. The problem is there are two transactions to the same account, than one must be considered as double spending and on the one hand must not be added to the block and it must be deleted from the transaction pool as well (as the nonce of the account already increased, there is no way that the transaction with the original nonce can be valid). As this is pretty much compatible with the classical UTXO based systes, it might not be the most performant solution and it might cause problems at use-cases where the only use-case is not just money spending, and there might be several actors working with the same account.

- Even with a simple money based blockchain system, it might be the use-case that I create to transactions in the same time for the same account in a way that they spend less money than the total amount of the account, and I certainly expect that both transactions are executed. If they are executed in the same block, the situation is actually solvable, as the miner can check and validate the transactions, and increase the nonce accordingly. However it might be a little bit tricky if the two transactions are executed in separate rounds, because the miner gets them in separate rounds from the transaction pool. 
- From a conceptual point of view however, the simplest consideration is to assume one account one transaction. In such situation a standard use would send one transaction at a time. If she wants to send several transaction as a batch of transactions, the wallet would simply create a set of transactions with an always increasing nonce. If coincidentally one nonce gets refused for some reason, the wallet can again create and sign the transaction with a bigger nonce. 

Trade of for showing information in a blockchain wallet or explorer

A blockchain wallet, usually stores only the local keys in the wallet, or from efficiency reasons some of the cached information. However everything that is relevant, like the balance of an account, the data of an account, or the existence of a transaction is stored on the blockchain. This implies an interesting dilemma for a wallet or even blockchain explorer implementation: which data should be shown to the end user. The two major versions might be  the followings:

- showing the most up-to-date data, in extreme cases even transactions that are already in the transaction pool but are still not confirmed. This solution might have the problem, that in case the blockchain forks, that might happen often on the top of the chan, the data will be changed or even disappear. 

- showing data only after a certain number of confirmations, like 3-10 have the advantage that the data will probably not change due to standard changes. However it has the disadvantage that the data might be simply old. 

A good solution might be to show every piece of data in a blockchain explorer or in the wallet with a kind of a reliability information as well, how much confirmation or reliability does the piece of data has. If it is a low-reliability information, it might be changed on a long run. In certain situations, there might be more than one different piece of data with different reliability as well, meaning that the data has been changed but the change itself is still not fully confirmed.   

How to implement a Blockchain from scratch - tasks of a miner

As opposed to the common idea, the task of the miner is not only to calculate the hashes. Its task in a blockchain system is to create a new block with a set of valid transactions and state information. The most important tasks are the followings in an accoun/balance based blockchain system:

- Choose one of the top block of the different partly competing blockchains: as the top of the blockchain always forks, one task of the miner or validator is to pick one of the possible top blocks and start building on top. As these top blocks are competing with each other a heuristic has to be used to choose a blockchain that will most likely the longest one. Miners or validators are cryptoeconomically incetivized to pick the most probable longest block.  

- Pick a valid set of transactions from the transaction pool. If a transaction is valid or not depends highly on the transaction itself. The transaction has contain a valid signature, its from and to address should either contain valid account or the related account should be able to add to the transactions. Transactions for double spending or replay attacks must be avoided. There might be further considerations for picking the transactions, like there might be transaction fee included that has to be maximized and there can be a limit for the available transactions as well.  

- Apply transactions to the state. How it is exactly carried out is again highly dependent on the transactions. If it is a transfer transaction, than the related balances of the related accounts have to modified. If it is a state modifying transaction, the state of the corresponding account has to be modified.  

- As soon as the set of transactions is chosen and the state is calculated, merkle or patricia root both for the transactions and for the state has to be calculated. 

- As a last but one step, proof of work has to been done, meaning that nonce values have to be fine-tuned until the hash value will be less than the given difficulty. 

- As a last step, the new block has to be boradcasted to the system. 

How to implement a Blockchain from scratch - adding system transactions

Adding a system transaction to a blockchain system is actually quite easy. Let we imagine the situation that we have something as a number of privileged accounts - they might be related to nodes as well and we want to initiate a transaction to adding a new one to these privileged accounts: 

- There must be a transaction that contain as an address one of the address of the privileged accounts. 

- There must be a state information in the blockchain containing the available set of system accounts 

- There must be a validation rule that not only validate the signature but checks as well if the related account is in the system state among the possible addresses. 

- There must be a state transforming rule, which in case the transaction is valid adds the new account to the state. 

The system can be started by adding to the first node a system right and then the first node can attach further nodes to the system account state. 

Optionally, there can be other special accounts or activities in the state that can be carried out only by system transactions. 

Certainly it is an open question if such a system is more vulnerable against forking attacks.

Such a system could provide the basis for realizing on-chain governance. Let we imagine the situation that difficult is a variable in the system state that can be modified only by system transactions. There might be one model that every authorized account can modify the variable, however we imagine that each transaction makes just a kind of a vote for the new value. If the number of positive votes reach a certain value, the new difficult will be considered in the future.  

How to implement a Blockchain from scratch - apply transaction to the state

Mining in an account/balance blockchain system practically means finding a set of consistent valid transactions and applying them to the system state. For this activity we need two sub-functions: on the one hand the, transaction has to be validated against the state, on the other hand the transaction has to be applied to the state. For the sake of simplicity we assume that each block stored the whole state, which is copied one to one at the initializing the block.

For a simple transaction only setting data, the pseudo code is the following:

ValidateTransaction (Transaction t)

if t.signature is not valid

  return error signature not valid

  else

    foreach account a in the state

      if a.address == t.fromAddress

        if a.nonce != t.nonce +1

          return error replay attack

        else

          return transaction is valid

      else

        add new account to accounts with fromAddress 

For a transaction transferring money:

ValidateTransaction (Transaction t)

if t.signature is not valid

  return error signature not valid

  else

    foreach account a in the state

      if a.address == t.fromAddress

        if a.nonce != t.nonce +1

          return error replay attack

        else

          if a.balance < t.amount

            return balance is not enough

         else

          foreach account a in the state

            if a.address == t.toAddress

              return transaction is valid

           add new account to accounts with toAddress

      else

        return error from account must exist at transferring money 

For applying the state we have to iterate on all of the account check them if they are valid and after that apply the state change. It might vary again based on the exact type of the transaction. If it is a simple data transfer transaction:

ApplyState (Transaction t)

  foreach account a in the state 

    if a.address == t.fromAddress

      a.data = t.data

for the money transferring transaction it is a little bit more complicated

ApplyState (Transaction t)

  foreach account a in the state 

    if a.address == t.fromAddress

      a.balance -= t.amount

  foreach account a in the state 

    if a.address == t.toAddress

      a.balance = t.amount

How to implement a Blockchain from scratch - minimum wallet

Wallet is practically a set of keys that is stored directly or indirectly in the local node. It is important to note that this is a wallet functionality of a blockchain node, which might have similar functionalities as a mobile or web wallet, however the implementation might be a little bit different. 

In an UTXO based system, a wallet stores the keys and a set of unspent transaction outputs that provide the possibility to read out balance without initiating a full blockchain search. In an account balance based system, a copy of the locally managed accounts are practical to store, with the corresponding private keys. This provides the possibility to read out balances or data in an efficient way. On the other hand, locally created but still not with the blokchain accounts have to be managed as well. 

An account has the flowing data;

- Accounts: a list of extended account information is practical to be stored, meaning the basic account information with the private keys and some flag if they are fully synchronized with the blockchain. If the private keys are encrypted, further information might be required as well.

A minimum wallet should implement the further functionalities:

- CreateNewAccount: creating a new account locally, generating a new public private keys and calculating the necessary further information. The functionality might be implemented differently, if it is a random wallet, hierarchical wallet, or hierarchical deterministic wallet. 

- ImportAccount: importing an account based on the private key.

- CreateAndSignTransaction: creating a new transaction which can be any type of a transaction like value transferring or data setting transaction. The transaction is signed by the private key of the related account might vary based on the type of the transaction. A value transferring transaction is signed by the private key of the sender address. After a successful signature, the transaction is broadcast ed into the network. A value setting transaction is signed by the private key of the account which value has to be set. The functionality might be separated into several sub-functionalities, like creation transaction, signing an existing transaction, and broadcasting into the network as three separated tasks.    

- GetBalance: getting the balance of an account or of the whole wallet. 

- BackupWallet: backing up the locally stored account information, especially the private keys. 

- RestoreWallet: restoring the account based on the backed up information, especially on the private keys.  

How to implement a Blockchain from scratch - transactions

Transactions are responsible in every blockchain to create changes in the system. Considering an account/balance based system, they are actually simple statements saying transfer money from an account A to account B, or change the state of account A for a new value. It is important that a properties of a transaction should be set only once, practically at the beginning, to avoid possible hacking attempts.  A transaction should contain at least the following elements:

-   TransactionId, it is actually a hash of all the important values of a transaction. Practically the hash of all of the previous elements. TransactionId provided on the one hand as a kind of a primary key for the transaction itself, the transaction can be identified based on this Id. On the other hand, it might provide a kind of a hacking resistance consistency the transaction is only valid if the TransactionId is consistent with the other values. It is certainly a question if the TransactionId itself should be stored on the blockhain or if it is enough to generate it. If we generate the value, we might miss one consistency guarantee, on the other hand we might as well save storage space on the chain. At any case TransactionId is practical if we want to refer to created but still not signed transactions on the client side.  

- Nonce: the value should avoid replay attacks. It should be set by the wallet software as an incremental value of the account nonce. 

- Address: the address of the account that we want to modify, or from which address we want to transfer cryptocurrency. If the address is the public key, this field should contain the public key, if it is calculated value of the public key like with hashing or double hashing, than this calculated value should be here. 

- Signature: valid transactions must have a signature, which is the data of all relevant information in the transaction, signed by the private key. The signature is generated by the used cryptographical algorithm, like with the help of Elliptic Curve Cryptography. In case we have TransactionId as well, than this id should not necessarily be presented in the signature. The reason for that is that we might want to administrate valid but still not signed transaction on the wallet side. 

Depending on the exact transaction type we can have further properties as well. It is important to note that in a given system, we might as well several different kinds of transactions, like one for transferring money, and further ones for setting data, like in case of an identity management system. 

- ToAddress: if our transaction is a value movement transaction, we will need the address where we want to move the money. 

- Amount: in case of a value movement transaction, we will need the amount to transfer as well. 

- Data: if our transaction is meant to register data in the blockchain, we will need the new data value as well. 

Transactions need to have the following functionalities: 

- Create transaction: in a way that all of the important properties can only be set once.

- SignTransaction: with a private key and a given cryptography the signature of the transaction can be created. The signature should be in case as well to be able to set only once. 

- VerifyTransaction: based on the signature, exiting data parameters and public key, the signature can be verified. If the public key is directly the address, the signature is simple. If the address is derived with a hash function from the public key, the public key must be also given as an input.

Advanced scenarios might have further functionalities as well, like creating raw transactions, or partially sign transactions. 

  

How to implement a Blockchain from scratch - accounts and balances

There are two kind of a blockchain: 

1. UTXO based systems stores only transactions with inputs and outputs represented as practically coins, an output is practically spent, if there is a transaction which refers with an input to the output of the other transaction.

2. In state based systems there is an explicit representation of an account which contains a balances or other information as data.  

An account has the following data structure:

- Address : it is a public key or the hash value of the public key.

- Sequence : it provides a protection against a replay attack, in simplest case it is an integer, in more complicated scenarios it is a kind of a ring of hashes.

- Balance: if the blockchain solution implements cryptocurrency either externally or as an internal cryptoeconomical incentive, there must be a variable for that of a type double or float. 

- Data: if the platform implements something other that cryptocurrency, we can have some more data elements as well, like a string or strings for identity management or an array of key value - value pairs for a general smart contract system. 

- AccountId: it is questionable if account id is required, as the account address should identify the account as a primary key. The implementation of such an id is the hash of all or some data in the account. On the one hand, It provides some more consistency and hacking resistance, on the other hand however, the value should be recalculated at every new value assignment or balance change.

If the account of a wallet is not stored in the blockchain but in the local wallet, than further data and functionalities should be taken into consideration:

- Private Key: As the wallet creates and signs transactions if the account, private key of the account has to be stored as well, either in a plain or an encrypted version. It is important that private keys should somehow, directly or encrypted, be stored on the wallet side, but they must not be stored in the blockchain. 

- Syncronised with the blockchain: if we create a brand new account with the help of the wallet it might still not be added to the blockchain. It can be added to the blockchain at the first transaction (like at changing value of the account or at transferring money to that transaction), or it can be added with an explicit transaction. Independently if the account is added to the blockchain, at each round there might be a synchronizing round that synchronized the account values from the blockchain state to the local wallet account store.

As a functionality one should provide the following services on the wallet side related to the accounts:
- GenerateAccount: creating a brand new account, means creating a new private and public key with a cryptography and key generation mechanism, like eliptic curve cryptography. The private key should be given back to the user and stored in the wallet account possibly with a corresponding symmetric encryption mechanism. If the address of the account is not the public key directly, the address should be generated from the public key, like with a help of different hash algorithms. 

- ImportAccount: the account should be created with the help of an input private key. Public key and address should be generated based on the given cryptographical protocol. As this is not a brand new account, the data of the account must be synchronized from the blockchain.
- SyncAccount: the data, balance and sequence parameters of the wallet account should be updated based on the latest reliable values from the blockchain. 

From a conceptual point of view, accounts that are stored by a wallet are the accounts that are administrated by the wallet. In an account/balance based system, they are similar as storing the list of unspent transactions in an UTXO based blockchain platform.

There might be more than one different style of account in the system, similarly as externally owned and smart contract accounts in Ethereum. Typically one can be responsible only for storing the cryptocurrency balance, as others for storing data on the blockchain.

Block headers in a multi-hash blockchain system

From a practical point of view a multi-hash blockchain means a kind of a multi-header blockchain system. For each hash pointer or each pair of hash pointers we have to save a:
- nonce for each hash pointer
- difficulty for each pair of hash pointers
- general retention policy for each pair of hash pointers
- actual retention policy for a given hash pointers

At calculating the new hash of the hash pointers, the following data should be taken into account:
- all the information that is stored in the hash pointer and was previously mentioned
- the hash values of the previous hash pointers
- merkle root of the transactions
- merkle or patricia root of the state

The block of a multi-hash system contains:
- several hash links
- the transactions
- the new state

Types of blockchain governance

One of the critical part of every blockchain solution is governance. It is especially valid for blockchain platforms, like Bitcoin or Ethereum, but it is actually the same for blockchain applications that are realized on the top of a platform. Governance means carrying out changes or further development of the application. There are several models that has different advantages and disadvantages in the practice:

- Off-chain governance means that the governance model is totally independent from the blockchain itself. Changes of the platform is proposed by a community or trusted people and both the implementation and the implementation is carried out by these people as well. Such a model has the advantage that it is technologically less challenging, however it might cause a split in the community resulting a split or hard-fork in the platform itself as well. Such models are realized by Bitcoin and Ethereum where improvements are presented by improvement proposals, like Bitcoin Improvement Proposal (BIP), or Ethereum Improvement Proposal (EIP). The model caused several hard-forks in the above mentioned platforms, resulting for example Bitcoin Cash, or Ethereum Classic. 

- On-chain governance means that several elements of the platform is able to change by a community decision, and both the decision mechanism and the change implementation is supported by the platform itself. Such an example is the difficulty increase or decrease mechanism of the Bitcoin network which is hard-coded in the consensus mechanism and is practically relized by the voting of the miners or the voting of the stakeholders. Other platforms like Monero have much further developed on-chain consensus mechanism, as an example part of the transaction fee is collected into an online wallet as an improvement budget, which can be used for further development or even marketing projects based on the voting of the community. 

From another perspective blockchain governance can be categorized on the fact, who makes the decision. From this point of view there might be the following models: 

- Centralized governance: systems like Ethereum has a pretty centralized governance. From a practical point of view almost all of the changes are governed eventually by Buterin. It has certainly, the advantage of being able to adapt fast, however not necessarily truly open as participation. 

- Open governance: Systems like Bitcoin has a real open governance model. Practically everybody can initiate new changes in the system and the implementation of these changes require a pretty open consensus as well. Practically the core developers, the miners, the exchanges and the shops should all agree in order that a change is implemented successfully. As it is almost a pretty open democratic process, certainly it can be very slow and inefficient in the implementation phase.

- Governance by trusted actors: There can be model between the two previously mentioned examples as well, where several trusted (and sometimes well known) actors can initiate and implement changes in the platform. Such governance model will be implemented directly by Hedera Hashgraph. Similar initiative can be found like in Dash or Monero, where indirectly the stakeholders or the master node responsibles can be regarded as trusted actors.