Second Layer Solutions: Deployment and Development Obstacles
The current transaction processing performance of the Ethereum network makes it unsuitable for all but the slowest of commercial applications. As seen during the viral ‘Cryptokitties’ phenomenon, when the Ethereum blockchain effectively ground to a halt, Ethereum desperately needs a solution for its scaling issues. Transactions on the main chain are often subject to high latency and unpredictable fees, further undermining the case for widespread commercial adoption.
Enter nahmii, hubii’s second layer (or layer 2) scaling solution for Ethereum. nahmii uses the Ethereum blockchain for deposits, withdrawals and security oversight, while abstracting the majority of transactions off-chain. This multi-party state channels construction allows for radically improved transactional throughput relative to the main Ethereum network, as well as predictable fees and greatly reduced latency. nahmii is designed to complement Ethereum, retaining the security features of the base layer while solving Ethereum’s main issues.
Building nahmii has not been without challenges, so as part of hubii’s commitment to engaging with the crypto community we have decided to share some of our insights here. The first requirement for nahmii was high transactional throughput; we settled on a baseline figure of 15 transactions per user address per second. The true performance of nahmii may well exceed this figure, but we felt that providing each user with the approximate performance of the entire current Ethereum network was an excellent starting point. Our most challenging target use case was something like a pay per action website or computer game, where the user might interact with the host system multiple times per second. While 15 transactions per second per user may seem like a lot in that scenario, it’s easy to imagine an IoT use case where higher throughput per device is needed.
Scaling for an unlimited numbers of users
Next, nahmii was aimed at commercial-scale applications. Most of us at hubii come from an engineering or scientific background, with a proven track record of delivering tangible products. As such, we wanted to play to our strengths and build robust, scalable products for the most demanding customers possible. The goal was therefore to make nahmii massively scalable, able to effectively add an unlimited number of users to the platform without compromising performance.
A high performance scaling solution like nahmii requires a significant degree of optimisation from every system component. In our effort to provide a groundbreaking, scalable platform, we encountered several technical hurdles and obstacles. Due to the size constraint of smart contracts, deploying each contract within one block on the Ethereum mainchain has become an issue; this has led to numerous re-factorisations of entire smart contracts within the nahmii platform. We have surpassed 60 smart contracts in total, some of which will not be deployed as stand-alone but rather serve as base contracts of others. Due to the feature-rich nature of the nahmii scaling solution (payments, fraud detection, etc.), the size constraint of smart contract deployment has become a challenging factor that required a significant effort from our development team to resolve.
Etherscan and verifying smart contracts
Etherscan’s functionality was another technical landscape that we’ve had to navigate. Etherscan’s inability to verify our smart contracts after deployment to the Ropsten testnet was an obstacle we didn’t anticipate. The public interface of a number of our contracts relies on v2 of the ABI coder, features that are still considered experimental by many compilers. Etherscan has confirmed that their Verify Contract tool is not supporting v2 yet. Some time has passed since our last deployment to Ropsten testnet and our last attempt to verify code in Etherscan; we anticipate that once Etherscan has updated their contract verification tool, nahmii’s on-chain transactions will be publicly verifiable at Etherscan. While we address the Etherscan on-chain transaction verification issues, we’re in development of the off-chain transaction verification platform, nahmii explorer.
Deploying individual updated contracts
Another challenge we faced was how only to deploy smart contracts that have changed since the last deployment. One of the key aspects to consider when deploying smart contracts is that it’s not optimal to deploy what has previously been deployed unless there has been a feature update in the code. We use Truffle for our deployment and development needs. Their migration features are targeted primarily at deploying a set of new contracts by the addition of new migration files. This was a significant obstacle for us, since we wanted to focus on deploying just a specific subset of contracts whose code had been modified and subsequently rewire references accordingly. To remedy this issue, we developed a deployment pipeline that allows us to choose which specific contracts to deploy without duplicating contract deployment and, in turn, cut associated contract deployment costs.
For developers by developers
nahmii’s development is remarkable for many reasons, not simply because we have already built the protocol. We are also building tools (CLI, SDK, API) on top of the protocol that will give developers with little to no blockchain experience the ability to build solutions using nahmii with a minimum technical overhead. This is something we’re putting a great deal of effort into currently, running workshops with companies where we can bring their development team up to speed on how to use the protocol. To cross the barrier for adoption, nahmii has to resolve existing transaction issues for our users and provide the tools to get outside developers up to speed quickly and efficiently. In other words, ultimately, we built a solution for developers by developers which should be usable by experts and blockchain novices alike.
