ETC: Wanted, Dev or Alive
This post accompanies the talk I’ve done at EDCON 2019 in Sydney, Australia.
My work in developer relations for the Ethereum Classic Cooperative has granted me amusing insights into what is needed to promote development and hacker culture in a cryptocurrency community.
The thing about cryptocurrency development communities is that open-source hackers now need lawyers and PR people online to represent them. Every development decision seems to be tied to a political decision, giving rise to what I think is the developer-activist type.
Developers can instead utilize the tribalism that exists across chains to build more diverse dapp strategies.
What The Fork Is Going On Here?
This post is NOT about ETC vs. ETH communities.
This post is for development use-cases from ETC for ETH developers.
It is also about how unique networks become a feature for the developer to take advantage of when deploying their smart contracts.
Now, before we begin, I want to clear one misconception that often has plagued the ETC community for a while. Personally, I find it hilarious.
Or when ETCDev went bankrupt, the joke became “Look, everyone, all the ETC developers are gone!”
Either way, it has become a joke within our community as we slowly build tools that we hope are useful for other crypto communities.
This post will explore those tools and how blockchain developers can utilize them.
Topics I will be covering here:
- Kotti and Goerli Testnets
- Ethernode
- Mantis Client
- Open-RPC Standard
- Research Work
- Development Use Cases
Kotti and Goerli Testnets
One of the most important projects that we had the honor of funding early on was the Goerli project for ETH and the sister project Kotti for ETC.
Having Proof of Authority test networks is very useful for smart contract developers that quickly want to deploy their contracts to test without having to wait to mine a few blocks.
I wrote a guide for deploying an ETC smart contract on Kotti using v0.5 Solidity, but it also applies for Goerli network if you want to try it.
I’ve noticed sometimes it’s hard to communicate both Goerli and Kotti at the same time and it’s usually just called Goerli, even though ETC is the sole funder of the project. So, I’ve looked for solutions to call the project something else.
There recently has been discussions about the names of the currency. On Goerli, they’re calling the currency GoEth, pronounced Goth.
I proposed Ketsy, but Anthony Lusardi (pyskell on Twitter) proposed ketchup. I like ketchup as a name for KETC.
To combine both project names in a show of unity, I propose calling the project Gothic Ketchup.
Ethernode
Ethernode is possibly the most exciting project I have seen in the blockchain space because it’s a perfect marriage of a few things I love:
- Customized hardware
- Blockchain node as IoT security.
Ethernode is one of the main projects funded in the first cohort of ETC Labs and a vital member of the ETC community.
Ethernode’s hardware and OS aims to support all Ethereum-based machines, so Ethereum developers can get their hands on one and develop for whichever Ethereum-based network they prefer.
It supports Multigeth and Mantis, and comes with a mesh network that supports B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking) which will allow each Ethernode peer running an EVM client to discover one another in a decentralized way. So, node discovery physically becomes decentralized, which is freaking awesome.
Ethernode also comes with EnOS, the Linux-based operating system for decentralized dapps running on your own hardware.
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
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.
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.
