Voice of the MANXers: Series #5
The fifth MANX Ask Me Anything (AMA) was held on September 24, 2018 and focused on Testnet. It was conducted in the MANX telegram group.
This session was led by Beichen Huang (Super Server Chief Architect, Head of Development Team in Canada) and John Hua (Director, System Development), and moderated by Yawei Cui (co-founder) and Olivia Fan (Head of Operation). This transcript has been edited for clarity.
Olivia: What do you mean when you say that MANX is a “super server”?
John: MANX is a Blockchain as a Service (BaaS) platform, providing developers and end users with a rapid application development/configuration infrastructure. It’s a high throughput scalable blockchain with post-quantum security mechanism.
MANX features an extensible multi-chain architecture that is the basis of a core high-performance main chain. Decentralized applications require customized closed-loop operating environments to perform effectively on subchains.
Yawei: What is the plan for Testnet Milestone #1?
Beichen: MANX Testnet provides layer 1 network module (P2P / Gossip mechanism), layer 2 auto adaptable (accelerated aggressive mode / fallback conservative mode) PoS PBFT consensus engine, and interface to application layer (layer 3) implementing key account management module with on-chain token transfer.
RPC and REST interface will be made available for client testing, application integration and development of application templates in the next phase.
The application layer will provide the following features to be a full-fledged blockchain implementation, including a fundamental staking module and a cross chain (main chain/sub chain) MVP module
Olivia: Could you introduce the development team?
Beichen: MANX has a strong, mature and multidisciplinary development team with senior researchers, experienced enterprise architects, engineers and developers supported by experts in marketing and token economics. The technical team has expertise in all major fields including P2P protocol, consensus protocol, cryptography, networking, dApp and GUI development, security and high-availability deployment. The team also has strong experiences with blockchain ecosystem cultivation.
MANX has development teams in Toronto/Ottawa Canada, Hong Kong, Nanjing China, and Suzhou China. In total there are about 25 full-time resources working in parallel on different areas of the project. The teams use JIRA for project management, GitHub for code repository and social media/tele-conference tools for efficient communications. So MANX has a dedicated team working basically around the clock.
Automated regression testing is utilized when new features are integrated, bugs and issues are assigned classified priorities to get resolved and are then added to our internal corporate knowledge base.
Yawei: Is there any plan to release an intermediate version prior to milestone #1?
The answer is: no, there is no plan to release a publicly accessible Testnet environment before milestone #1. Incremental versions will be released and tested internally prior to that milestone.
Olivia: Many MANXers have asked about Github. Is the code repository publicly available?
John: MANX does have a publicly accessible GitHub repository at https://github.com/macrochain and selected code is posted there. MANX will keep updating the repository with relevant information throughout the development phase.
However, MANX doesn’t expect to publish the complete MANX core for public access before go-live in order to protect certain critical intellectual property.
Please also refer to our website http://www.macrochain.io/ and social media channels for news releases. MANX will also publish technical updates on Medium.
Yawei: Beichen, could you provide some more detail on the MANX Testnet deployment environment?
Beichen: Sure, developers implement software on their local physical machines and deploy to a small local network for testing. The official Testnet will be deployed on AWS with approximately 20 nodes initially in North America, Asia and Europe. We anticipate expanding this to around 100 nodes. A reasonably large portion will be validator nodes.
MANXer G: Has the team worked on any other projects?
John: The team is leveraging our experience with Cosmos/Tendermint, Ethereum, Quorum and other blockchain projects. MANX is taking an innovative approach to developing the MANX core. Main features include:
1. accelerated/fallback dual mode operation
2. main/sub chain integration
3. multi-crypto support
4. light client support
5. post-quantum encryption
6. heterogeneous multi-chain integration
MANXer G: What are your core design and implementation principles?
Beichen: MANX uses best practices and the following design/implementation principles in the implementation:
1. Multi-tier approach — blockchain, Application-Blockchain Interface (ABCI), blockchain application, REST interface for integration with non-blockchain applications
2. Loosely coupled technology stack with modular design
3. Pluggable modules like consensus algorithms and encryption algorithms
4. Tools to allow creating new applications or extending the application layer features through pluggable modules
The MANX Core provides the networking and consensus layers of blockchain to support application layer implementation, and to communicate with application layers via a dedicated protocol called ABCI (comparable to the Cosmos implementation.) ABCI is language agnostic, meaning that developers can build application modules in different programming languages. The networking and consensus layers (layers 1 and 2) are being implemented in the Golang programming language, while the application layer (layer 3) supports any programming language such as Golang, Java, .Net, Python, etc.
MANXer G: what is expected performance of the MANX core?
John: Based on PBFT/PoS consensus, in an ideal network scenario, the MANX core is able to operate in accelerated aggressive mode and handle a large number of transactions in a short timespan.
Block time can be as low as one second and can process thousands of transactions in that time period. Under adverse network situations e.g. long network latency, congested network with jitter, and overloaded nodes, MANX core falls back to conservative mode. New blocks get created within three seconds.
MANXer G: How much tolerance does the MANX core provide?
Beichen: The MANX core features an “instant finality” consensus algorithm, meaning that forks are never created. Users can rest assured that their transactions will be finalized as soon as a block is created, making it easier to implement cross chain transactions.
MANX is 1/3 fault tolerant in fallback mode and 1/5 fault tolerant in accelerated mode. A fork in BFT (Byzantine Fault Tolerance) PoS permissioned blockchain is only possible when at least 1/3 of the validators are faulty. Fork accountability holds validators accountable by identifying those that cause a malicious fork and slapping them with a heavy fine by having their bond deposits destroyed.
Olivia: how do we keep the MANX core safe?
Beichen: Let me explain our approach. To keep the MANX core safe, we will offer an incentive for the community to hack committee nodes — our Hack bounty program. The bounties grow proportionate to the size of the validator, so a committee member becomes a bigger target as its stake grows.
Secondly, the MANX core uses top-class enterprise security best practices, cryptography algorithms, and secure deployment to keep the system safe.
Finally, the MANX project plan reserves 5 months to run extensive testing and bug bounty program with the user community trying to eliminate as many vulnerabilities as possible.
Yawei: How are the proposer and committee member selected, how many committee members will there be, how will you measure this setting and is there any plan to increase that number?
John: Under the accelerated aggressive mode, a designated static proposer/accelerator is adopted, which accepts all new transactions, signs them, and sends them out to committee members for signature. In the fallback conservative mode, the MANX core rotates through the validator set to select a block proposer for each block in weighted round-robin fashion. This algorithm is deterministic.
Ideally no less than 100 validator nodes will be deployed. The best trade-off between efficiency and security will be carefully considered and tested in Testnet.
Yawei: What’s the protocol for communication between Committee members?
John: MANX implements its own gossip protocol to achieve networking P2P and consensus in a novel way. Peers leverage the gossip protocol to broadcast ledger data in a scalable and efficient fashion.
Yawei: What’s the incentive to join the committee / act as a validator to maintain the accelerated mode?
John: Validators secure the MANX network by validating and relaying transactions, proposing, verifying and finalizing blocks. Validators can stake their own deposits or be delegated from other stakeholders.
Validators collect transaction fees and will have a positive payoff after subtracting operating costs. Thus validators have an interest to keep online, act honestly and operate efficiently. Slow and faulty validators will be removed when the system falls back to conservative mode.
Yawei: How does MANX toggle between the two modes?
John: The MANX core maintains a state flag indicating the current execution mode — accelerated or fallback. Under adverse situations when consensus cannot be made on time, the system switches to fallback mode.
Within the cool-down period, the committee stops signing messages. After the system switches to fallback mode, the most recently signed transactions will be posted by any node then get incorporated into the blockchain by newly elected leader/proposer. To recover from the fallback mode, the committee can renegotiate and elect a leader to enter the accelerated mode again when the situation improves.
However, if the system falls back to conservative mode again within a short period of time, the MANX core will use an exponential backoff algorithm to re-enter aggressive mode.
MANXer G: how do you guys prevent Long Range Attacks?
Beichen: LRA can be mitigated as follows. First, for a validator to unbond (recovering their collateral deposit and no longer earning fees to participate in the consensus), the deposit must be made non-transferable for an amount of time known as the “unbonding period”, which will be two to three months. Second, for a light client to be secure, the first time it connects to the network it must verify a recent block-hash against a trusted source, or preferably multiple sources. This condition is sometimes referred to as “weak subjectivity”.
Finally, to remain secure, it must sync up with the latest validator set at least as frequently as the length of the unbonding period. This ensures that the light client knows about changes to the validator set before a validator has its capital unbonded which could allow it to deceive the client by carrying out a long-range attack by creating new blocks beginning back when it was bonded (assuming it has control of sufficiently many of the early private keys).
Olivia: Can you introduce our cross-chain aspect?
John: MANX cooperates with blockchain consortiums, stakeholders and other blockchain service providers for cross chain specifications. The goal is to maximize interoperability.
The IBC (Inter-Blockchain Communication) protocol of MANX assigns authorization of the packets to the source blockchain’s consensus algorithm, performing light-client style verification on the destination chain.
The Byzantine-fault-tolerant properties of the underlying blockchains are preserved because a user transferring assets between two chains must trust the consensus algorithms of both chains. The source chain posts block headers with validator set and Merkle tree proofs to the destination chain, while the destination chain only needs to validate the hash to enable secure verification of individual packets.
The mechanism naturally defines two types of transactions: one allows a blockchain to prove to any observer its most recent block-hash, and the other allows a blockchain to prove to any observer that the given packet was indeed published by the sender’s application, via a Merkle-proof to the recent block-hash.
Cross chain will be implemented in a phased approach, starting from main chain/sub chain to heterogeneous main chain/side chains including but not limited to Ethereum, Bitcoin, EOS, etc.
MANXer G: How do you tackle the Nothing-at-Stake problem?
Beichen: The Nothing-at-Stake problem is dreaded in PoS consensus systems because it allows Byzantine actors to steal within the network at no cost, penalty or consequence.
MANX requires anyone who wishes to serve on the committee to put down a deposit/stake that is proportional to their voting rights. Their stakes will be slashed if they don’t participate properly.
MANX also demands an unbonding period (several months) when unlocking the deposit/stake.
Yawei: Has consideration been taken to avoid monopoly / consortium? How will MANX prevent concentration of stake in the hands of a few top committee members?
John: The community is expected to behave in a smart and self-preserving way. When a mining pool in Bitcoin gets too much mining power the community usually stops contributing to that pool.
MANX will rely on the same effect. Given that 15% of the total tokens will be owned by the core team, 30% will be owned by the community and ecosystem development, there is a good chance the stake won’t be overly concentrated. Other mechanisms can be deployed to smoothe this process as much as possible.
Olivia: Regarding dishonest member Accountability, is there any penalty to dishonest members or inactive committee members?
Beichen: The question of dishonest member accountability has a simple answer — those found guilty are slapped with a heavy fine by having their bond deposits (stake) destroyed. Inactive member will be removed from the committee and a small amount of their escrow/stake might get slashed.
Yawei: How can committee/validator nodes protect themselves from denial-of-service attacks?
John: One way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture.
Validator nodes should only connect to full-nodes they trust e.g. those they operate themselves or that are run by other validators they know. A validator node will typically run in a data center with direct links to the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator’s node directly to its sentry nodes and requires new sentry nodes be spun up or activated to mitigate attacks on existing ones.
Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an Internet-based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to nodes in the rest of the network.
It is expected that good operating procedures on validators can help to largely mitigate these threats.
At the end of the AMA, Yawei shared a piece of great news: MANX and CollinStar have entered into a Strategic Partnership! A round of applause for our partner: CollinStar!
Our 6th MANX AMA focused on MANX technology is coming on October 3, 2018 at 7AM EST (11 AM UTC). To attend, please join our Telegram group at: https://t.me/macrochain