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.