Skip to content

Instantly share code, notes, and snippets.

Created April 11, 2022 12:40
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?

Callisto Network consensus mechanism thoughts

Currently Callisto Network runs POW Ethash similar to ETH and ETC. DAG size is >3 GB at the moment of writing. No modifications to the consensus method were applied.

The requirement for the platform

Callisto Network was originally designed to be a self-sustaining security platform. Therefore it was meant to implement system contracts - Cold Staking, Governance DAO, Auditing DAO. That's it.

We never advised users to develop DAPPs on Callisto Network even though we never prohibited it either. The thing is that the main feature of Callisto Network was that it intends to support only system contracts. For that purpose Ethereum's codebase was sufficient.

However, Ethereum itself as well as the newly developed platforms represent themselves as a "DAPP platform" i.e. a distributed application execution environment that runs thousands of applications simultaneously. In fact, EOS is designed to be a distributed operating system.

A financial system like Bitcoin has the only utility - funds transfers. Therefore the throughput of Bitcoin network can be compared to that of VISA or other financial systems that handle monetary transactions. However, a distributed application execution environment or distributed operating system has much more utilities - these include application invocations and application-to-application communications. If we would measure the number of interactions between different processes within the scope of one operating system running on one computer then the result would be comparable to the whole number of interactions on Ethereum network. We should keep in mind that in real circumstances the Ethereum must no only handle one user, but a number of users each of which may invoke their desired applications and cause new application-to-application communication chains.

Financial platform can have bandwidth sufficient for financial transactions. Application execution environment platform must have bandwidth to handle much more on-chain communication patterns.

Comparison of throughput of POS, DPOS, POW

Network Consensus type TPS metric
Ethereum family (ETC, ETH, CLO) POW 20 tx/s
TRX DPOS 2000 tx/s
EOS DPOS 2402 tx/s
Solana DPOS 65000 tx/s
PIVX 2-layered POS 173 tx/s
DASH POS-POW hybrid 34 tx/s

With the current configuration Callisto block time is ~12 seconds and a GasLimit of a block is set to 5,000,000 gas. Empty transaction consumes 21,000 gas so CLO network can process up to 238 tx/block.

This results in approximately 20 tx/s bandwidth.

Solana is supposed to have a maximum of 65,000 tx/s bandwidth (even though it is not known for sure if it is true or not).

EOS experience 2402 tx/s under the peak congestion in 1.8 update. These are the real results of on-chain activity. In theory the EOS is capable of running up to 3996 tx/s as per EOSIO description.

TRX is supposed to have 2000 tx/s metric as per wikipedia.

DASH can process 3 million transactions per day i.e. DASH has ~34 tx/s. Real environment testing

As the on-chain metrics suggest DPOS consensus types have overwhelmingly higher TPS metrics than their POS / POW-POS hybrid counterparts. POW is the slowest in this case.

Virtual machine that executes smart-contracts

I wrote it a number of times that I consider EthereumVM and solidity to be a very bad structural decision:

In short words, it is way more progressive to rely on widely supported virtual machines designed for embeddable applications such as WASM:

While it may not be directly related to the consensus mechanism, it is still better to rely on newer codebases and stick to the most up-to-date solutions that would support the implementation of new tools in the future.

Therefore, while picking a consensus mechanism development direction I would strongly advise against the development of something unique and rather stick to already-existing solutions with a further goal to re-implement a better virtual machine. This means that the closer we are to the code base of a project that is likely do develop an implementation of WASM or any VM that is superior to EVM - the easier it would be for us to merge with their updates.

Transaction fee & the problem of microtransactions

Another well-recognized problem across the smart-contract development industry is the problem of micro-transactions. In fact, if the cost of a transaction (or any on-chain action) is non-zero then it causes the impossibility of building a range of services that require interactions between its parts.

Another problem is that new users can't transact at all (unless they purchased the initial small amount to cover fees and sent it to their account).

Historically POW chains have the highest transaction fees and none of the POW chains have free transactions. In a range of DPOS systems transactions can be free or the cost can be abysmally low.

  • In TRX a user can send up to 15 free transaction per day. After that the cost of transaction becomes $0.00012 / tx
  • In EOS a user should rent resources for a given period of time. The cost of renting $0.00003 / tx. Alternatively a user can stake EOS for CPU/NET and then perform a limited number of free transactions once per 3 days.
  • In CLO $0.000004 / tx paid every time a transaction is sent.

The cost of infrastructure

POW infrastructure

Running POW chains requires constant infrastructure maintenance.

  1. Miners run mining software which creates dependancy on external parties such as mining software developers. Without a proper support of mining software a chain can experience significant problems.
  2. Miners run pools. Pool operators tend to hold significant power in decision making process when it comes to protocol upgrades. It is even harder to coordinate a protocol upgrade as it requires the distribution of mining power which overcomplicates the process. Without a proper support of mining pools it is hard to mine a particular chain which can create additional burdens.
  3. A range of hashrate attacks are possible so a set of network monitoring tools is required.
  4. Bootnodes must be maintainted by the developers. Miners rely on bootnodes but they do not run them.

DPOS infrastructure

DPOS infrastructure is less reliant on externally developed software as the consensus does not require anything aside of a properly configured node. In addition, top Validators can serve as bootnodes for the network.

  1. Voting support an wallet maintenance. This becomes the main issue to keep wallet up-to-date in order to let users participate in the voting at any time.

Possible solution

It should be noted that Callisto has the following options:

  1. Stay on POW
  2. Switch to TRX-like DPOS
  3. Rely on Ethereum's Casper experience
  4. Tokenization. It is possible to create a CLO-token on top of an already-existing chain (such as Ethereum, EOS or TRX) and re-implement core features of the Callisto there (Cold Staking, Treasury) and then scrap the chain altogether making the CLO-token the main currency of the project.

Benefits of staying on POW

While POW has a number of disadvantages, many of them are only relevant to smart-contract execution environment platforms. For as long as Callisto does not experience the surge of DAPP activity nor expects to improve it's characteristics to attract DAPP developers it is not that relevant to pursue the advantages of higher bandwidth.

Staying on POW may attract mining powers when Ethereum switches to POS. The increase of hashrate can be a positive signal for investors. The only competitor in this are is Ethereum CLassic as there are little to no viable Ethash platforms at the moment.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment