Developers can quickly spin up clients, test their Solidity code in the browser, as well as take advantage of IPFS, use our open-source explorer, wallet and whisper protocol.

This screenshot above shows three Ethernodes, each running ETC, Kotti, and ETH respectively and communicating between one another over Whisper. That’s freaking cool.

Mantis, A Scala EVM Client

Mantis is a Scala client by IOHK that is the first native Ethereum Classic client.

Most recently, the Mantis team has opened up support for ETH, so ETH developers and node operators can run Mantis right now.

Mantis will also be included inside EtherNode along with Multi-Geth.

Benefits of using Mantis include leveraging IOHK’s bad-ass formal verification team to build the client, making it one of the more secure Ethereum-based clients in town.

OpenRPC

Open-RPC aims to be documentation-driven standard for interfacing with JSON-RPC 2.0 APIs. This enables a very readable language by both humans and machines to understand the entire capabilities of a service in RPC, where the documents are generated as well as the client.

This is important as it means no more using web3.js glue on top of your RPC calls, you just call the RPC endpoint directly like `getBalance`. This has important impacts because if your RPC endpoints are standardized and specified from the get-go, there’s no need then to have 200 libraries that rely on a wrapper for RPC endpoints to each get updated manually whenever there’s a change.

While OpenRPC is a fork of OpenAPI, it’s exclusively for JSON-RPC endpoints, stripping away unneeded elements and requests like GET (JSON-RPC only does POST requests), allowing users to have a library focused on the blockchain first.

Ethernode currently has OpenRPC in it, which is a great testament to the collaboration between Ethereum Classic developers working together.

There currently exists an EIP proposal as well for OpenRPC, submitted by Shane Jonas (@ shanejonas on Twitter) of ETC Labs Core team, as well as a BIP. OpenRPC can become a standard across all blockchains.

Research Work

IOHK has done what I like to call “magic math” type of research in the fields of formal verification for Cardano and Ethereum Classic.

A lot of that research has been proposed for ETC, and can even be applied to ETH based networks.

For example, NiPoPoW (Non-Interactive Proofs of Proof-of-Work) are what are described as “stand-alone strings” which allow you to verify an event happened on a PoW network without being online or downloading all the block headers. It can verify for example that a payment transaction took place.

This has major usage for mobile-based applications which try to be optimal on performance and space.

IELE is a variant of LLVM (a collection of modular and reusable compiler and toolchain technologies) specialized to execute smart contracts on the blockchain.

It’s based on the experience of the teams working with K framework for language semantics (of which KEVM, the semantics for Ethereum Virtual Machine, was also funded by IOHK).

IELE brings the benefits of having a register-based machine vs. the stack-based machine of EVM.

This allows it to have a uniform gas model where there’s no limit but one can pay for whatever they used based on how many registers are consumed. More registers used, more gas consumed.

This also allows for more secure smart contract to be written because of the requirement specifications that smart contracts can obey. It also doesn’t have a bounded stack, so worrying about arithmetic or stack overflow will be a thing of the past.

Finally, in terms of data analysis, recent projects where we uploaded Ethereum Classic’s dataset to the cloud on Google BigQuery and Kaggle will open it up for more data scientists who want to analyze the network. Doing comparisons between both networks post-DAO is a very interesting field some members of our community are pursuing.

Development Usecases

Tribalism Between Chains

Networks with different characteristics on the economic and social layers can provide developers with additional properties for their dapps that can be taken advantage of.

For instance, deploying on ETH makes sense if developers want to utilize the latest features and cutting-edge tools in decentralized ecosystems but are willing to trade-off on long-term security.

With ETC, developers can deploy smart contracts more tailored to dealing with sensitive data, knowing that social layer properties like immutability and trust-minimization can be utilized as further protection over their smart contracts.

For developers, networks become a social layer feature that can aid them in their dapp design, specifying which smart contracts to deploy to which networks depending on their use cases.

The relationship between both ETH and ETC can be like how Debian distributions are split between nightly and stable, where more cutting edge solutions and features hit Nightly first before later on getting adopted in Stable. In this way, ETH can be looked at as Debian Nightly while ETC is Debian Stable.

Some of you may be aware that there have been discussions between ETH 2.0 core developers and ETC core developers and stakeholders regarding ways to collaborate together.

The call was to explore ways we can have collaborations between the two chains, and one of the more obvious approaches, which was later championed by others in the ETC community, revolves around ETC being a base-layer Proof of Work chain for ETH 2.0 Layer 2 solutions.

The idea was to either have it along with ETH 1.x as the base layer or have ETC on its own as the base layer depending on what happened to ETH 1.x once the whole ecosystem transits to ETH 2.0

The diagram below is from a proposal by Donald McIntyre for ETC providing base layer PoW for ETH 2.0.

The possibilities for collaborating there are endless, ETC can provide a lot of advantage to Ethereum-based developers with its adherence to Proof-of-Work and Immutability social principles, which can provide advantages to developers deploying smart contracts to both chains.

They can deploy to ETC to take advantage of maximum security over new features, which they can use ETH 2.0 for.

The security through PoW, immutability, lesser new features, supply-caps that make ETC like a Store of Value, allow for more interesting smart contract combinations.

It’s a way to look at ETC.

If ETH is to become a World Computer, then ETC will become a World Vault.

Gringotts Bank

A world vault isn’t a store of value, but rather an entire system that operates to protect the store-of-value currency. One great way to envision ETC is like Gringotts Bank from Harry Potter universe.

Gringotts Bank uses magical security systems and transportation between vaults in order for wizards to withdraw their valuable gold and silver coins, which is what ETC is aiming to do with research in formal-verification, promoting immutability principles on the social layer, and discovering new ways to securely build smart contracts that operate with world value.

The future of ETC is exciting with the many possible paths to take in the directions that adhere best to the principles of the network. Developers can take advantage of that to build the best dapps possible that can combine both chains.