The First Technical AMA of MASS: Smart Contracts, Two-Tier Plug-ins and Cross-Chain Can Be Realized

Max, a technical geek fond of learning source code who has been paying attention to the technological progress of various blockchain projects in recent years, learned about MASS project through massnet.org last year and was attracted by its innovation in PoC.

The following are 8 high-quality questions about MASS technology collected from the MASS community, to which Max has given great answers.

Q1: Why are you optimistic about PoC? What’s the greatest technological innovation and the current technological difficulties of MASS?

Max: There are mainly four reasons I’m optimistic about PoC.

-Fairness: In PoC consensus algorithm, the proof of capacity is decentralized, and the proof of capacity provided by a miner is linearly related to his rewards. If miners want more revenue, the best way is to expand the capacity. Such a mining algorithm allows individual miners and large miners to mine on an equal basis.

-Security: A well-designed PoC mechanism can resist malicious nodes with less than 51% capacity.

-Scalability: PoC consensus algorithm takes capacity space as the proof. Therefore, after the hard disk is initialized, there’s no need to consume too many additional resources to provide capacity proofs for multiple blockchains.

-Energy saving: The energy consumption of nodes that have been initialized and are in the process of mining is reduced by orders of magnitude compared to PoW.

The greatest technological innovation of MASS lies in the redesign of a more advanced PoC consensus mechanism compared with projects such as Burstcoin. Each capacity proof of MASS only needs to read a few bytes of data from the hard disk, as well as ensuring extremely high security.

Friends who have viewed the PoC code of MASS must have read the following code:

This piece of code is the core proof verification function of MASS, which is proof of capacity. In short, any legal proof in MASS should satisfy the condition: It is known that function P can map the numbers in the value range Nx to the value range Ny, function F can map the value range (Nx, Ny) to Ny, and both functions cannot achieve the inverse operation, which means the input cannot be reversed even if the result is known.

(1) The proof consists of three parts: x, x’ and BitLength. When verifying, first calculate P(x)=y and P(x’)=y’ with function P, and at this time y and y’ satisfy the bit reversal relationship under the bit length of BitLength. For example, 100110 and 011001 satisfy the bit reversal relationship with BitLength=6.

(2) Then use function F and input (x, x’) to calculate F(x, x’)=z. z and the random number challenge obtained in the business logic of the chain go to the same result after truncated with BitLength.

These two rules complete the proof of capacity. Friends who have plotted in MASS must have noticed that table A and B will be generated when plotting in MASS, which correspond to steps (1)(2) above. With such design, any space with a capacity of 32GiB can proof its 32GiB storage capacity only by reading data with a total length of 8 bytes from table B.

Compared with the previous PoC algorithm, this design is a huge improvement. The proof data structure of MASS not only reduces the reading pressure of the miners’ disks to an extremely low level, but also makes it only require a few hash calculations for the proof verification of ordinary nodes. Therefore, MASS has achieved the features of fairness, security, scalability and energy-saving.

The technical difficulties mainly focus in the field of cross-chain, which will be discussed in detail later.

Q2: Is it difficult for MASS to implement smart contracts? Does it need a hard fork?

Max: The transaction structure of MASS contains a special field: Payload. I suppose the introduction of this field is to facilitate the implementation of various applications including smart contracts.

As we all know, the account models of Ethereum include Nonce, Balance, CodeHash and StateRootHash. Among them Nonce is used to prevent replay attacks, Balance to record the Ether balance of the contract, CodeHash to index the operation logic of the contract and StateRootHash to index the storage state of the contract.

MASS can analyze Payload by introducing a new OpCode to support the specially designed smart contract virtual machine similar to EVM.

There is a high probability that the community need to reach an agreement and the change is achieved through a hard fork. Soft forks can work as well, but the security of old nodes may be weakened, and therefore hard forks may be a better choice.

Of course, whatever the change is, firstly we need to consider the transaction throughput and the difficulty of ordinary running full-nodes after the hard fork. A balance needs to be reached between them.

If there are really complex and necessary requirements, you can even design a separate parallel chain driven by MASS to run smart contracts, which can also satisfy the demand.

Q3: Parachains can be sent on the MASS engine, then what is the difference with Polkadot and Cosmos? What kind of ecology do you think MASS is going to create?

Max: The information on the official website shows that MASS was designed to support the parallel operation of multiple blockchains and the cross-chain interaction.

This cross-chain protocol is different from Polkadot and Cosmos for the chain independence is stronger on MASS.

In the first question, it can be seen that the design of MASS has reduced the pressure of miner nodes on the disks. Therefore, for the MASS system, it is totally feasible to support the parallel operation of multiple chains at the mining pool level.

I think the advantage of the design is that the chains can be dedicated to specific usage while reducing extra energy consumption. For example, MASS Net is based on the UTXO model, and some business logic is more suitable for the account model in Ethereum, so the community organizations can develop an account model chain based on MASS consensus. Different businesses are distributed to several segments of the chains, instead of containing everything in one chain, and I suppose it is more conducive to the development of the whole ecology.

According to the current documentation and code of MASS project, I reasonably guess the final MASS ecology will be:

(1) Miner networks jointly constitutes the Layer 0 consensus layer based on MASS PoC.

(2) Multiple chains with different data structure are running in parallel to form the Layer 1 data layer.

(3) Cross-chain interaction based on the cross-chain protocol constitutes the Layer 2 application layer.

Q4: What are the advantages of using Golang for MASS source code?

Max: Golang is in a relatively balanced position in the trade-off between development efficiency and running speed, which can save a lot of development time while ensuring the performance.

Meanwhile the existance of blockchain projects developed in Golang (including Hyperledger Fabric, Ethereum, Filecoin, Btcd, etc) has further promoted the prosperity of blockchain toolkits written in Golang. Therefore, some new blockchain projects tend to develop in Golang.

Besides, there are also significant advantages in cross-platform and deployment. Supposing that a friend plans to run MASS Net on the Raspberry Pi, but the corresponding binary is not provided on the official website. Then he can still download the code to compile the binary for linux/arm64 version without modifying the code, and run it on Raspberry Pi.

In conclusion:

- Golang is in a relatively balanced position in the trade-off between development efficiency and running speed.

- There is a large group of developers in the field of blockchain.

- Plenty of open source toolkits related to blockchain are available.

- Cross-platform and easy for deployment.

Q5: If there is a hard fork of MASS in the future, what will it be like?

Max: If MASS undergoes a hard fork, it will be technically similar to Ethereum in implementation.

As the pseudo code in the figure below shows, suppose that we add some opcodes from the height of 1,000,000 to support better performance of smart contracts; but if a new opcode appears before the fork height, the transaction script will be considered invalid. It will be reflected in the code as a similar function:

Here is just an extension of the soft fork problem. As we all know, Bitcoin’s soft fork has a complete set of procedures. For example, miners can vote on the corresponding proposal by modifying certain bits in the Version field of the block header, and if the number of consecutively agreed blocks reaches a certain threshold, the soft fork will be activated.

In addition to the block header and transaction area in MASS Net, a proposal area (ProposalArea) is additionally designed. Each proposal contains two fields: ProposalType and Content. The current code stipulates that ProposalType==0 and ProposalType==1 represent penalty proposal and penalty proposal placeholder respectively. And ProposalType>=2 will be parsed as an arbitrary message and will not be verified. This is exactly a method that can be compatible with soft forks, and MASS Net may increase some proposal types for soft fork voting by miners in the future.

(Please noted that MASS has already undergone a hard fork on July 31.)

Q6: How many times has MASS been halved?

Max: MASS has completed the fifth halving so far. Its halving cycle mechanism is that each halving interval is twice as the previous one.

Therefore, MASS has halved at the block height of 13,440, 40,320, 94,080, 201,600 and 416,640 respectively, and the next halved height will be 416640 + (416640–201600) * 2 = 846720.

If anyone is interested in the code related to halving, please go to GitHub to have a look.

Q7: The vision of MASS is to provide an underlying consensus mechanism that can aggregate other PoC chains. Is this vision reflected in the code?

Max: Currently the core code of MASS PoC is located in the ‘poc’ directory under the MassNet-miner project.

By studying the ‘poc/engine’ directory, we can find that MASS has encapsulated the relevant PoC engines into a three-layer structure, namely: MassDB, SpaceKeeper and PoCMiner. And their positioning is:

- MassDB: The producer of Proof and the container for storing Proof.

- SpaceKeeper: The manager of the Proof container, which can provide PoCMiner with the required Proof according to different contexts of blockchains.

- PoCMiner: The consumer of Proof data, which can produce new blocks according to the logic customized by the developers.

Under the MASS consensus, the consensus of multiple chains is completely consistent at the MassDB layer, for they share the same consensus layer. The difference is that, there are different query methods at the SpaceKeeper layer and different rules for block production at the PoCMiner layer according to different chain strategies.

Totally speaking, the three-tier structure has already embodied the vision of convergence. Meanwhile, the structure of block header of MassNet also reflects its planned support for multiple chains, please have a look:

Every block in MASS records the ChainID obtained according to the unified calculation rules, and the ChainID of MassNet is ‘5433524b370b149007ba1d06225b5d8e53137a041869834cff5860b02bebc5c7’. I believe that the ID is designed for the convenience of multiple chains running in parallel.

Q8: Is it easy for the MASS mining pool to support multi-mining?

Max: Conclusion goes first: It’s rather easy.

In the previous question, we have seen the layered design of MASS PoC engine. It can be seen that no matter which chain is based on the MASS engine, it is completely consistent at the MassDB layer.

The SpaceKeeper layer usually involves a little information related to the blockchain context, but the basic logic of MassDB query is still the same.

As for the PoCMiner layer, it is customized according to the mining strategies of different chains.

In conclusion, if the MASS mining pool hopes to support multi-mining, it needs to customize the logic of PoCMiner and slightly change the logic of SpaceKeeper without changing MassDB. In total, the difficulty of support is acceptable.