Introduction to CBDC (Central Bank Digital Currency)

Over the past year, new news has appeared in the press on a daily basis that various central banks are experimenting with, or analyzing the implementation of, Central Bank Digital Currency (CBDC) in detail. Perhaps the best is the Swedish and Chinese implementations, where specific test applications also exist and specific deployments are also planned. In this article, we analyze some possible implementations of digital central bank money and the issues it raises.

The “hype” of digital central bank money these days is not entirely coincidental. The following four important market forces influence the topic’s prominence:

- Demand for digital money and digital value transfer services has grown significantly in recent years. This trend is expected to intensify significantly due to the emergence of COVID-19 and similar epidemics. Of course, there are online financial services, but most of them try to digitize the concept of paper-based money well and are not digital in a native way.

- Technological “push”: As a result of ten years of development of the blockchain and cryptocurrency, it has reached the level to implement commonly used digital money systems. Slowly, a digital central bank can also be a realistic technological alternative. In addition, as it is almost completely open source in the field of blockchain, it is one of the most dynamically evolving technologies for value transfer.

- The private sector is beginning to recognize both market demand and technological opportunities, and services are beginning to emerge that could be competitors to even non-digital central bank money. Examples of such projects are stable cryptocurrencies or the Facebook Libra project.

- Last but not least, competition with several central banks is an important factor. The first to introduce internationally accepted digital central bank money can bring significant benefits.

The concept and characteristics of digital central bank money can most simply be summarized through the taxonomy of money.

Digital central bank money:

- Completely and “natively” digital.

- Issued by central banks, ensures the stability of the digital money exchange rate and is officially legal tender within the borders of at least one country.

- P2P, if not absolutely necessary for the technological implementation, but at least in the sense that any two persons or companies can exchange values ​​without a separate authorization mechanism for a central actor.

- Available to economic operators. Here, some terminology distinguishes between two different CBDCs: the so-called Wholesale CBDC only allows value exchange between banks and other financial institutions, while the Retail CBDC is available to other actors in the economy.

- Most ideas are that the new digital central bank money would be implemented on a new digital value transfer infrastructure that would be more modern, secure and flexible than current systems.

- Another general expectation is to support open financial digitization and innovation such as programmability, tokenization or nano-payments (micropayment).

The following figure shows a comparison of Bitcoin and a generic CBDC without details of the technology implementation. The most important difference is that while in the case of Bitcoin most of the platform parameters (monetary policy, when and where to access the service) are “hard-coded” in the software, in the case of CBDC they can be defined by institutionalized, e.g., central bank decision makers.

In terms of implementation, two independent dimensions are usually considered. Based on the structure of the CBDC, it can be:

- Account-based: in this implementation, each user would create this online account with the central bank, similar to a normal bank account. However, the advantage of the solution is its ease of implementation, but the disadvantage is that the central bank would have to issue end-user accounts and would be a direct competitor to commercial banks.

- Coin (Token) based: here the CBDC would be implemented with the help of digital coins issued and withdrawn by the central bank, either directly or indirectly through financial institutions to economic agents. In monetary terms, the system is similar to paper money-based systems and requires more, but with a good chance, new financial infrastructure (eg blockchain). However, token-based systems are expected to have several advantages over account-based systems, e.g. decentralization, flexibility, greater security and privacy.

Regarding the structure of CBDC, two main models are known:

- Single-tier: here, the central bank is in direct contact with all economic agents, either by keeping their accounts or by issuing them with digital coins. The disadvantage of this solution is that, as the central bank emerges as a direct competitor to commercial banks, it could cause a restructuring of the entire financial sector, which could significantly shake up overall financial stability.

- The tiered system would reflect the current institutionalized financial hierarchy, where the central bank would provide CBDC services to economic actors not directly but through other financial institutions.

The following figure shows a possible digital dollar implementation with token-based digital dollar issuance and a multi-level structure that would build on the current banking system.

CBDC is often associated with blockchain and distributed general ledger technology. It is important to note, however, that most analyzes also consider multiple technology implementations, such as classical financial infrastructures. The main barriers to implementation with DLT are the scaleability, performance, and privacy limitations of each technology platform. While these are not insurmountable barriers, most blockchains may not be suitable for the full implementation of a CBDC use case without modifications. Nevertheless, successful prototypes have been born with consortium Ethereum supplemented with off-chain channels and on the R3 Corda platform.

The most interesting question, of course, is when the first digital central bank money will be born and what we can try. It is difficult to give a general answer to this, but given that several countries are in a strong test phase with their own currency, it is likely sooner than we think.

Ethereum parity node and monitoring

If you run a parity node one of the most important is to check if your sync is running or if it is stopped for some reason. Making sure that the json-rpc is enabled, you can use two checks:

1. Check if the sync is fully synced. 

curl --data '{"method":"eth_syncing","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

if you get a false for the above command, it is fully synced. Otherwise you get the actual block number where the sync stays.

2.  Even if it is fully synced, the ancient block sync might be running, so the following command has to show that the blockGap is null:

curl --data '{"method":"parity_chainStatus","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

Blockchain and identity

Today’s systems for managing digital identity and identity are deeply rooted in the analog world and can only be used sparingly online. The most common authentication solution is to enter a username and password, where you usually need to enter an additional phone or email. The real role of this is not only the possible password reset, but also that the email or phone number provider has a good chance of doing some kind of additional offline identity verification. On the one hand, this makes the person using the service somewhat traceable to the extent absolutely necessary, and on the other hand, the system prevents so-called sybil hacking: a person creates a large number of anonymous users. In more critical cases, credit card or bank information is also used for a similar purpose.

However, username-based authentication solutions have several problems. With the proliferation of online solutions and the increasing complexity of password requirements, most users use a single username, email, phone number, and, in the worst case, the same password for most services. This poses a serious privacy and security risk. Of course, users can also be blamed for this, but it is not necessarily realistic to securely store 200 completely different names and passwords for two hundred different online services. On the other hand, basically neither the email nor the SIM nor the credit card system is designed to identify users, so their use for this purpose is difficult in most cases.

On the other side of the scale are classic paper-based documents, either identity documents or digital versions of them. Scanning or photographing any such paper document does not implement exactly the same mechanism as the original paper-based certificate. The problem is that the digital copy can be duplicated and easily modified. This again raises some serious security and privacy issues. In a slightly different perspective, the Internet was unfortunately designed 30-40 years ago with the built-in support of digital identity not being a priority, so any such but basically analogue-based solution is only moderately workable.

Technologies that combine blockchain and digital signature (so-called Blockchain Identity Stack) try to provide a solution to the two major issues mentioned above and to digital identity and authentication in general. The main building blocks of such systems are:

Decentralized Identifiers (DID): Identification is based on a public and secret key pair, similar to blockchain systems. In a blockchain system, my public key, or the address generated from it, shows exactly who I am and, blockchain rules (or eg smart contracts) describe what I am entitled to. The fact that I “physically” really belong to that address is evidenced by signing a message with my secret key (which, ideally, only I have). In this sense, in blockchain systems, a digital signature is actually personal identification.

This concept is generalized by decentralized identifiers. Compared to the foregoing, such identifiers may contain, in addition to the public key or address, a number of different pieces of information, such as data relating to a particular person or entity, in the form of a document. For more information on such an identifier, what blockchain solution it supports: most productive systems are optimized for one blockchain type, such as Ethereum, but there are initiatives for those used in multiple blockchains. Last but not least, some systems also support so-called organizational IDs, where you have to sign not only with one but also with several private keys to prove your identity.

Decentralized identifier (DID)

Verifiable Credential: The verifiable certificate model is the digital equivalent of paper-based certificates. In the model, the Issuer issues a Credential to a Holder, and then this certificate is verified by a third party. A classic example is the issuance of a university degree: here the issuer is a university, the owner is the student who received the degree and the certifier is, for example, an employer who wants to verify the authenticity of the degree. In contrast to the paper-based solution, however, here we identify each actor with decentralized identifiers:

-    Diploma handover: the university enters its public ID in the diploma and then signs it all with its secret key

-     Diploma receipt: the owner attaches his own public ID to the previous data and then signs it with his secret key.

The blockchain in the system serves to ensure the consistency of the certificates as a public and difficult to hack database. Thus, when an identifier such as an employer verifies the authenticity of a diploma, it checks the consistency of the data on the blockchain and that it was indeed signed with a secret key that belongs to the university. And for the fact that the diploma really belongs to the owner, the owner has to produce a separate signature with his secret key.

With the above building blocks, a system with several pleasant properties can be implemented:

-    We do not use a username, password, phone number or credit card or other inappropriate information for identification, only secret keys.

-    Not only the entire certificate can be submitted for validation, but also parts of it. So, for example, it is possible to share with the prospective employer, in the verifiable way mentioned above, when the person graduated and where, without having to share the specific grade. Because the blockchain also contains only the hash values ​​of the certificates, maximum GDPR compliant systems can be implemented.

-    The DID that forms the basis of the identification can be generated by everyone themselves, in fact, the key pair generation is the basis. It does not work by assigning these IDs in a centralized way to “someone”. This is why these systems are also called “self sovereign identity”.

The issued certificate can be revoked, usually by a blockchain entry revoking the issue.

-    Although its system is based on the secret key that players store in their digital wallets, losing the key is not as critical here as it is with a cryptovalent. For example, if my secret key to owning a degree is stolen, I can go in person to the university, where I can revoke the diploma certificate from the lost key and re-issue it to a newly generated decentralized ID. Of course, it involves pursuit, but it is by no means impossible or critical.

-    I can make my own separate decentralized ID for each online service I use. Thus, each service can be used with maximum privacy.

Overall, it is worth noting that such an implementation of digital identity goes far beyond storing a digital identity on a mobile phone. Although secret keys can of course be stored on a mobile phone, in real use cases, some secret keys will probably be stored in several different places, such as laptop, special hardware device, cloud solution. In addition, several different solutions will be available in case some identity-related keys are stolen or lost.

An analysis of the 2018 crypto market collapse and the following crypto winter

Anyone who has been dealing with blockchain and cryptocurrency technologies for a couple of years may still remember the market crash in 2018 and the one and a half year crypto winter that followed. The situation is well reflected in the bitcoin exchange rate shown in the figure below. Of course, the volume of the total kritpo and blockchain market is much larger than the current price of Bitcoin. However, since Bitcoin is used in most places as an interface crypto currency to enter and exit the crypto world, the chart below also shows the general cryptoconditions in 2018 quite well.

The Bitcoin price from 2014 to nowadays

First of all, it is important to note that we believe the blockchain is basically a transformative exponential technology. Exponential technologies have been evolving slowly for quite some time, and then, after a while, reaching their exponential stage, they are being used at an ever-accelerating rate (Figure 2). One of the best examples of this is artificial intelligence, and machine learning. If we consider only the backpropagation algorithm in the narrower sense as the birth of the area, the area has been in existence for more than 45 years. Nevertheless, we are not yet there for self-driving cars to travel on the roads on a daily basis, but it is conceivable that we will reach it within 5-10 years. This means 50-60 years until the technology reaches its true exponential stage, where it will actually result in radical innovations. Blockchain algorithms have been around for about 10 years. We believe that this technology will reach its exponential stage faster than artificial intelligence, but it may still take 10 to 20 years.

Life cycle of an exponential technology

On the other hand, general human thinking tends to underestimate the impact of a technology, especially if it is exponential: we tend to overestimate the effects in the short run, while we underestimate the effects in the long run. This is probably due to the structure of the human neocortex, which specializes in pattern recognition that is basically close to linear, so it also tries to approach an exponential change linearly. From another approach, the high level of media attention in the area caused a problem. With fundamental long-term technological change, the media tends to go to extremes: for example, to advertise something as a world-saving technology for half a year, and then, if it doesn’t change the world in six months, to declare it unusable.

Another feature of blockchain technology is that it is an infrastructure financial technology. In this respect, it is somewhat different from a simple fintech application that tries to save the world with a fancy mobile app and some business logic. It is more like classic infrastructure technologies such as the highway from which a few thousand kilometers have to be built in order for other applications to run on it, such as cars, trucks, motorcycles, and so on.

In 2015-16, a new application related to blockchain technology, called token sales, appeared, the earliest form of which is ICO (Initial Coin Offering, Figure 3). Token sales as a technology has fundamentally liberalized the investment market, both on the demand and supply side:

- On the demand side, it provided a new opportunity for any investor to acquire a stake in a startup starting up anywhere in the world on a basis of up to a few dollars.

- On the supply side, it provided an opportunity for a startup to raise funds from anywhere in the world, even in crowdfunding style in the form of individual investments of a few dollars.

In this sense, the problems arising from the short-term perception of the aforementioned exponential technologies have intensified even more than usual. Simply put, the blockchain is a technology that can implement its own financing as well.

Number of ICO-s around 2018

The biggest problem with ICO technology has been the complete lack of regulation in specific business implementations (and in some places this is not fully clarified today). This did not cause too much of a problem in the initial period of 2015-16, as it was mainly serious professional projects that carried out token sales, and since the technology was not very well known, mainly professional investors could be found in the market. By 2018, however, this has changed as a result of both the press publicity and the incredible exchange rate gains of the first successful projects:

- From the investor's point of view, investors who were not so much interested in technology or in the long-term success of a platform, but only in short-term exchange rate gains, began to dominate.

- As it was seen that there is quite a lot of “free money” in the market, startups have started to raise funds irresponsibly. Of course, there were also teams that did some serious project and teams that didn’t want to do anything just put away the funding they collected. However, most of the attempts were somewhere in between: since the funding was free, many tried to implement a project without worrying too much about whether there was or would be a specific market demand for it.

Overall, we believe that the factors mentioned above are:

- the beginning of the technological curve

- increased media attention and unrealistic expectations

- a liberalized investment market and "free money" without any regulation or control

they themselves have created an unsustainable market, inevitably creating an investment bubble.

The final push for a concrete market collapse was caused by a total regulatory fire that hit the ICO market in early 2018, but without it, the aforementioned scheme would probably not have been sustainable for a long time. The market crash was followed by a one and a half year crypto winter, causing significant difficulties for downsized and blockchain companies that incorrectly assessed market demand for their products, either because they paid enough attention to it or because the idea they came up with was too “early”. . During this period, it was very difficult to attract new funding from token sales, but classic funding was not always given to such ideas, so most of these startups failed.

The end of the crypto winter began roughly a year ago, when serious and at times conservative institutions began to enter the krito and blockchain market. Perhaps the first was Facebook, which, although it had banned posts and ads in this direction for years, still came up with its own blockchain and crypto platform. Facebook was followed by various institutionalized and controlled implementations by Swiss banks and, from 2020, by some German banks and the ICO, such as IEO (Initial Exchange Offering) or SAFT (Simple Agreement for Future Tokens), with moderate success for the time being. Last but not least, the European Union is testing its own blockchain platform, and J.P. Morgan, calling Bitcoin a scam for years, is launching its own Bitcoin-based investment services.

We might say a little biasedly that the future of technology is not in question, but individual business implementations and specific market developments already do. The emergence of enterprise-level institutions in the market does not preclude the emergence of similar bubbles at all, and in some cases they may even be much larger than in 2018, given that the capitalization of the entire crypto market is still far below the size of the dotcom bubble.

Dotcom bubble and the crypto hype

Introduction to decentralized finance

One of today’s re-used slogans is DeFi (Decentralized Finance). The term was originally developed in 2016/2017 for decentralized applications that attempted to implement financial services over a blockchain platform. The meaning of the word has now changed somewhat and we mean mainly decentralized financial (or at least similar to financial) services implemented in a smart contract over the Ethereum system. The strength of the system is that each decentralized service can be used not only in a separate way, but in combination with each other in almost any way. This creates a coherent and mutually reinforcing set of organic services.

The ecosystem is based on the following basic protocols and solutions:

Tokenization: Decentralized finance is de facto based on tokenization and various token standards. Tokens provide both technological and business integration between different DeFi platforms, and in most cases the internal logic of each service is also implemented with tokens. The two basic token types are the so-called fungible and non-fungible tokens. A classic example of a replaceable token is a coin, where, for example, one EUR 10 coin is fully equivalent and can be replaced by another EUR 10 coin. The best example of a non-replaceable token is a theater ticket, where one theater ticket is generally not equivalent, it cannot be replaced by another theater ticket for another piece and location. Standards have also been developed for various tokens, such as ERC20 or ERC223 for replaceable and ERC 721 for non-replaceable tokens.

DAO: The basic operating logic of most decentralized applications is a kind of DAO (Decentralized Autonomous Organization) decentralized autonomous application. The bottom line is that there are no centralized roles or administrators, but everything that needs to change dynamically is based on the votes or majority decisions of a community. A typical solution is to produce so-called “maintainer” maintainer tokens where token owners are maximally and financially interested in the good functioning of the system but can change certain parameters of the system with their votes. This does not mean, then, that everything works in a fully automated and immutable way, just that those who can change certain parameters of the system are interested in making the platform work well.

Decentralized Oracles: One of the critical points in applications implemented with distributed ledger technologies is the integration of external data into the system. Because external data is entered using a component outside the blockchain, the security or non-hacking of the system is particularly critical. A classic example is when the pay for a sports betting smart contract depends on the outcome of a sporting event that needs to be imported from an external data source. If the external data source gives the wrong value, the prize may not be paid to the right person. This problem is usually solved by reading the data from several different independent external sources so that each data provider is motivated by some token to give an authentic value. Such a prolotocyte is called decentralized oracles.

With the help of the building blocks mentioned above, several more complex services can be built, which can be used individually or in combination with each other.

Stable cryptocurrencies: The biggest problem with cryptocurrencies is the dynamically changing exchange rate. This is attempted to be eliminated by stable cryptocurrencies whose exchange rate is pegged to an external currency such as the USD. There are three main solutions for cryptocurrency exchange rate stability:

- The exchange rate is guaranteed in a centralized way by an external company or bank. Then, of course, the reliability of the system depends heavily on the company that guarantees a stable exchange rate. This is how Tether works, for example.

- Collateralized stable cryptocurrency. What typically happens here is that a person pledges a certain amount of cryptocurrency in a smart contract and a new cryptocurrency is issued for it. For example, in Maker DAO, $ 200 of ether must be tied up for $ 100 of stable cryptocurrency. This provides the system with stability against extreme exchange rate movements.

- The third solution is to change the supply and demand of money in a completely dynamic way: to increase the amount of cryptocurrency in case of a falling exchange rate, and to decrease the amount in case of an increasing exchange rate. It is important to note that this type of solution has not yet resulted in a long-term stable cryptocurrency.

Decentralized exchanges (DEX): The logical operation of decentralized cryptocurrency changes is similar to their centralized counterparts, the only difference being that they run entirely on the blockchain without any centralized mechanism or control. Their mechanism of operation can be divided into two parts: in the first phase, in order-book matching, the sell and buy options are paired. In most decentralized exchanges, order-book matching only partially runs on the blockchain, the main reason being the limited efficiency of ethereum. In the second phase, the crypto assets to be sold and bought are exchanged in a fully decentralized manner (settlement). Examples of decentralized exchangre are Compound, Kyber, 0x.

Prediction Markets: Prediction markets can be considered as a further development of decentralized markets: here you can place bets in cryptocurrency on the output of an event (such as tomorrow's average temperature) and make a profit if the output is hit correctly. The main use of prediction markets is not gambling, but the accurate prediction of certain events. The basis of the mechanism is the so-called wisdom of the crowd: if many independent actors predict the outcome of an event, moreover, with a financial interest in predicting the correct outcome, much more accurate predictions can be made than what some experts can achieve. Examples of such platforms are Augur or Gnosis. Prediction markets are often the building blocks of other decentralized online insurance services.

P2P lending: P2P lending platforms provide the possibility of crypto or token-based interpersonal lending in some form of interest-like construction. Lenders and borrowers are usually paired through a decentralized smart contract-based system and the specific business is done through it. Examples of such platforms are EthLend or CoinLoan.

Decentralized portfolio management: Decentralized portfolio solutions typically manage a portfolio of some kind of non-fungible token. Portfolios can be created and run with different rules, such as open-ended or closed-ended, automatically or trader-managed, and so on. The technology also provides the ability to create so-called tagged portfolios, such as a green portfolio of only sustainable tokens.

Certainly, decentralized finance platforms are by no means completely problem-free. Their biggest drawbacks are their scalability and performance, which stems mainly from the limited scalability of the ethereum platform: 15 transactions per second and a turnaround time of around 2 minutes for secure processing. Another major problem is the legal uncertainty in the area.

In the long run, however, we believe there will be a solution to both problems. For example, Ethereum 2.0 is likely to provide an adequate response to scalability. The future of legal regulation is a bit questionable in which direction it will develop due to the over-regulation of the financial sector. However, as a long-term economic trend, we believe that if a business function can be implemented with two hundred lines of code without multiple institutional backgrounds, then it will be implemented with two hundred lines of code.

Hyperledger Fabric Java SDK timeout parameters

Decentralized consensus is difficult to fine-tune. It is even more complicated if the whole consensus is separated into several layers like at Hyperledger Fabric. Supposing you need to to fine-tune, or getting timeout error from the client SDK side during transaction execution, the following timeout parameters are to be considered:

 public static final String PROPOSAL_WAIT_TIME =  "org.hyperledger.fabric.sdk.proposal.wait.time";

public static final String CHANNEL_CONFIG_WAIT_TIME = "org.hyperledger.fabric.sdk.channelconfig.wait_time";

public static final String TRANSACTION_CLEANUP_UP_TIMEOUT_WAIT_TIME = "org.hyperledger.fabric.sdk.client.transaction_cleanup_up_timeout_wait_time";

public static final String ORDERER_RETRY_WAIT_TIME = "org.hyperledger.fabric.sdk.orderer_retry.wait_time";

public static final String ORDERER_WAIT_TIME = "org.hyperledger.fabric.sdk.orderer.ordererWaitTimeMilliSecs";

public static final String PEER_EVENT_REGISTRATION_WAIT_TIME = "org.hyperledger.fabric.sdk.peer.eventRegistration.wait_time";

public static final String PEER_EVENT_RETRY_WAIT_TIME = "org.hyperledger.fabric.sdk.peer.retry_wait_time";

 public static final String EVENTHUB_CONNECTION_WAIT_TIME = "org.hyperledger.fabric.sdk.eventhub_connection.wait_time";

 public static final String EVENTHUB_RECONNECTION_WARNING_RATE = "org.hyperledger.fabric.sdk.eventhub.reconnection_warning_rate";

public static final String PEER_EVENT_RECONNECTION_WARNING_RATE = "org.hyperledger.fabric.sdk.peer.reconnection_warning_rate";

 public static final String GENESISBLOCK_WAIT_TIME = "org.hyperledger.fabric.sdk.channel.genesisblock_wait_time";

The default values are the followings:

defaultProperty(PROPOSAL_WAIT_TIME, "20000");
defaultProperty(CHANNEL_CONFIG_WAIT_TIME, "15000");
defaultProperty(ORDERER_RETRY_WAIT_TIME, "200");
defaultProperty(ORDERER_WAIT_TIME, "10000");
defaultProperty(PEER_EVENT_REGISTRATION_WAIT_TIME, "5000");
defaultProperty(PEER_EVENT_RETRY_WAIT_TIME, "500");
defaultProperty(EVENTHUB_CONNECTION_WAIT_TIME, "5000");
defaultProperty(GENESISBLOCK_WAIT_TIME, "5000");
defaultProperty(TRANSACTION_CLEANUP_UP_TIMEOUT_WAIT_TIME, "600000"); //10 min.

Hyperledger Fabric Sizing: vCPU, RAM, Disk

Hyperledger Fabric sizing might be a little tricky. One way of doing is to design the number of Fabric specific components, like CA (Certificate Authorities), Peers and Ordering Services components, getting some baselines for the designed system and accumulating the result. 

Simple development or test systems, might contain one peer, one ordering services, one certificate authorities and one channel. Complex productive systems usually have several organizations containing at least two but rather three peers for each organization, several certificate authorities like one for each organization and a complex ordering services usually containing at least five ordering containers. 

Baselines for the container resources can be gained from different resources, like this one. The following tables contains possible sizing for each container as virtual resource. 

Dev / Demo system: 

- CA: 0.1 vCPU / 0.2 GB RAM / 20 GB Disk

- PEER: 1.1 vCPU / 2.8 GB RAM / 100 GB Disk

- ORDERING: 0.35 vCPU / 0.7 GB RAM / 100 GB Disk

Test / Pilot system: 

- CA: 0.1 vCPU / 0.2 GB RAM / 20 GB Disk

- PEER: 2 vCPU / 4 GB RAM / 200 GB Disk

- ORDERING: 1 vCPU / 1 GB RAM / 200 GB Disk

Productive system: 

- CA: 0.1 vCPU / 0.2 GB RAM / 20 GB Disk

- PEER: 4 vCPU / 8 GB RAM / 500+ GB Disk

- ORDERING: 1 vCPU / 1 GB RAM / 500+ GB Disk

Certainly the above number can be modified based on the used containerization and virtualization technology. 

An Austrian economical interpretation for the last 3 years of Blockchain

The Austrian school of economics provide a pretty good interpretation what was happening in the Blockchain space in the last couple of years. The ICO and token sales hype for three years caused a lot of investment coming into the space totally uncoordinated. The reason for this money pump was not only a speculation in the technology but the fact that the token sales technology liberated and disrupted the whole funding a investment industry. Due to regulation issues the investment source  was basically cut and a lot of company found itself in the situation of having the invested money but not capable to build up a system that can be sold to any customers. The last two years of market and technology free fall was among the others a cause that these companies not able to find real market for their products were slowly liquidated. 

Hyperledger Fabric tips and tricks - using time or date in chaincode

If you want to use in your chaincode the exact time or date, it is not a straigtforward thing, because, the different endorsement peers might have different time set and if your commitment information is not the same in all of your commitment peers, the transaction will not be accepted as a valid one. What you can use, is the timestamp of the transaction itself, like with the help of a chaincodeStub.getTxTimestamp() call.

Hyperledger Fabric tips and tricks - chaincode log ID

If you log your chaincode activity, like with the help of a standard logger, it is always a good idea to know for which call was your log message generated. You can use the  getTxId() function call to log the transaction ID for you message.