Blog > Authors > Brian McKenna

Ensuring ETC Network Security

Ensuring ETC network security - a comparison of 51% Attack Resistance proposals for Ethereum Classic

23 October 2020 Brian McKenna 4 mins read

Ensuring ETC Network Security

The Ethereum Classic network suffered from four 51% attacks between 2019 and 2020. Three of those attacks have occurred recently – with just weeks between each other – which resulted in expensive losses for stakeholders due to double spending and service disruption. A number of Ethereum Classic Improvement Proposals (ECIPs) followed after these attacks aiming to provide the immediate solution for 51% attack resistance.

IOHK, and ETC Coop have collaborated to provide Ethereum Classic stakeholders and the broader community with the knowledge and understanding on how to resist these issues. To support this activity, we have created a comparison document to showcase and summarize the different 51% attack mitigations. In it, ETC community members will be able to assess each proposal, understand any concerns, and be advised on how the ETC community can solve ETC network security issues together.

The ECIP that seems to be reaching adoption in the immediate term is ECIP 1100: Modified Exponential Subjective Scoring (MESS). MESS is a modified version of Vitalik Buterin’s Exponential Subjective Scoring (ESS) and aims to make larger chain reorganizations more difficult. However, we believe that it will not provide robust security and there is no guarantee that it will prevent further attacks. What’s most concerning, however, about MESS, is that it has not been formally studied nor has its security been proven. Moreover, a series of potential attack vectors on MESS have already been identified.

Checkpointing is the way forward

Checkpointing, on the other hand, can make 51% attacks impossible with deterministic confidence of finality. This approach grants the ETC core developer community a safe space to innovate and implement the more speculative proposals that are underway. These may include MESS, Reducing the dag, Keccak-256, and many others. Considering that ETC value and user experience is currently hindered by the low-confidence and subjective finality of MESS, MESS doesn’t provide high confidence for stakeholders to reduce confirmation times to desirable levels.

The Ethereum Classic network is a minority proof of work blockchain in the Ethash environment. As of October 08, 2020, the Ethereum’s network hashrate is ~248.16 TH/s, Nicehash’s hashrate is ~9.34 TH/s, while Ethereum Classic’s network hashrate is only ~3.47 TH/s . This means that Ethereum Classic’s hashrate is only ~1.5% of Ethereum’s and ~40% of Nicehash’s, which is just one of many other mining rental platforms. It should be noted though, that non-Ethash networks that are minable by general purpose hardware can also be turned on to Ethereum Classic, which means that the Ethereum Classic network is even more of a minority proof of work blockchain than represented by the Ethereum and Nicehash comparisons above.

It thus follows that the current security assumptions of the Ethereum Classic network no longer hold. Speculating ETC’s network security on ETH’s proof of stake timeline is also not a sustainable security strategy and arguably not competitive enough to increase the value of the network.

Looking to the future

Indeed, it goes further than that. ETC is at an important crossroads and the choices we make now will impact not only the future of the platform but of the whole ecosystem. Any 51% attack mitigation must be robust enough to give absolute certainty to ETC holders, users and service providers that their transactions will be secure.

We need to be decisive and resolute, while giving ourselves the time to get this right. If we adopt a suboptimal solution at this point, and there are further issues with the network, it is unlikely that our (thus far) patient stakeholders – especially exchanges – will remain so.

Our focus at the moment is rightly on mitigation. But let’s also ensure we remember the longer-term goal – the health and sustainable success of Ethereum Classic. Let’s move decisively to underpin the security of the network, and together look forward towards a new era of network growth, community growth and sustainable innovation.

This post was originally published on the ETC Cooperative blog

Building new standards for privacy and scalability

IOHK joins the conversation around zero-knowledge proofs at the ZKP Workshop

20 May 2020 Brian McKenna 6 mins read

Building new standards for privacy and scalability

Building privacy and agency

In the age of information capitalism, data is a commodity which needs to be protected on an individual and global level. Every time someone makes a purchase, logs into an account, or accesses a website, metadata is connected to their individual IP address. Mass amounts of information move around the world every second but if it is not secured through encryption it can be exploited. The downstream effects of this can be benign, such as receiving targeted marketing. Or they can be dangerous like spreading political propaganda.

Privacy is central to the ethos of the crypto space. In terms of cryptocurrencies this has historically made many uncomfortable. Much of the early negativity around Bitcoin was linked to the perception that it was an untraceable enabler of the shadow financial system, from money laundering to global terrorism. But growth and greater awareness of data breaches, corporate and governmental overreach and ‘surveillance capitalism’ has shifted mainstream mindsets. Privacy has become a significant and legitimate concern for many, particularly with the arrival and potential fallout from the recent pandemic. Cryptography is recognized as an important tool for keeping institutional and governmental power in check and ensuring that data is kept by the people.

An individual’s personal information and metadata are their property. If they choose to share or sell access to their digital trail then it is their right. However, third parties currently take advantage of their stewardship over user information. This is why at IOHK we see it as our responsibility to investigate all technologies that might be used to enhance privacy, personal agency, and inclusive accountability.

New cryptographic approaches to address data security concerns have been a growing and significant area for IOHK research. We have produced more than 60 peer-reviewed academic papers, which have become an open-source, patent-free resource for everyone. Five of these papers relate to zero-knowledge proofs and their global application. They cover innovations in zk-SNARKs, privacy-preserving smart contracts and techniques for initializing these systems on blockchains in a more efficient and trustless way. But what are zero-knowledge proofs?

ZKProof Workshop

Zero-knowledge proofs, or ZKPs, are a cryptographic technique that, when applied to blockchains, can make them ultra-private and scalable. ZKPs allow information to be verified without being revealed to anyone but the intended recipient. In essence, zero-knowledge cryptography allows you to prove that you know something without revealing what that is. In the end, ZKPs protect people’s individual sovereignty and self-ownership. This is achieved using encryption to secure information while ensuring certainty and confidentiality when interacting with data sets, finances, and applications.

IOHK believes that these proofs represent an important step forward for universal inclusion, personal data management, and security. That is why we have been both sponsoring and participating in the third annual ZKProof Workshop, which concludes tomorrow.

This online conference brings together leading cryptographers, researchers and companies to advance the conversation around ZKPs. ZKProof’s open-industry academic initiative is focused on broad adoption of ZKP cryptography through the development of standards and frameworks. These international standards create a common language for applications, security, assurance and interoperability.

IOHK believes that the world will one day function through a nexus of interoperating distributed ledgers. This global network will combine legacy financial institutions, current tech companies, and emerging decentralized organizations. A global system like this will have to work equally for everyone. For that to occur, developers and engineers need to build common, trusted specifications and standards around privacy. They also need to ensure that immutable sources of information can be accessed by everyone. The workshop aims to define this framework for ZKPs. Ensuring privacy isn’t enough to build our worldwide system, we also have to make certain that it is accessible to all.

Power to the edges

IOHK has stated that its goal is to push financial and social power to the edges of society rather than siloing it at the center. To that end, we have to ensure that everyone has equal access to the single source of truth that is the blockchain. Things like state-dependent contracts and smart contracts require a large amount of space and computing power to maintain. This is a challenge given the fact that we want our platform to be equally accessible from high-powered desktops in London to cellphones in rural Uganda.

As blockchains grow they must also include multi-asset functionality, identity, and even voting. This is far from simply exchanging money or tokenized assets. All of these interactions involve maintaining and curating large amounts of information. For an individual to verify the source of truth from the node level of the blockchain, it would require petabytes and eventually exabytes of storage space. This is untenable for any user. Fortunately, ZKPs provide a solution to the problem.

Recursive construction of zero-knowledge proofs allows transactions on the distributed ledger to be truncated so that even as the blockchain grows, the necessary capacity to host the full node remains achievable for all participants. ZKPs bring both privacy and scalability together, which makes them a critical stream of research for IOHK engineers. The result of this is increased universal understanding and inclusion.

Inclusive accountability

Zero-knowledge cryptography isn’t just a scientific or academic stream of research. It is directly applicable to a variety of global challenges. ZKPs help create inclusive accountability. Inclusive accountability is the idea that there is universal verification for every actor running an algorithm on their computer or device. While ZKPs can be used to account for private monetary transactions they can also be used for casting votes, transferring records, and securing personal information. In essence, inclusive accountability is built into all of the most important processes that govern the world, laying a foundation of trust for everyone.

The focus of the ZKProof Workshop is to set standards that will pave the path to adoption of zero-knowledge cryptography. IOHK believes that these cryptographic tools are the key to addressing emerging challenges within our future financial and social frameworks. If you'd like to be a part of the conversation surrounding ZKPs you can still sign up to join the online ZKProof Workshop.

Check out our recent papers and our open source implementation of the Sonic protocol:

  • Mining for Privacy: How to Bootstrap a Snarky Blockchain
  • Sonic: Zero-Knowledge SNARKs from Linear-Size Universal and Updatable Structured Reference Strings
  • Kachina: Foundations of Private Smart Contracts
  • Ouroboros Crypsinous: Privacy-Preserving Proof-of-Stake

IOHK releases Icarus to the Cardano community

Developers can now build their own light wallets

15 August 2018 Brian McKenna 7 mins read

IOHK releases Icarus to the Cardano community

Today IOHK releases Icarus, a reference implementation for a lightweight wallet developed by the IOHK engineering team. We hope that this code base will be used as a point of reference to enable developers to create their own secure light and mobile wallets for Cardano. Icarus is a fully open source code base that will be the first step in a range of open source initiatives to provide developers with a suite of tools for Cardano.

Icarus was born out of a series of proof of concepts which began back in March of this year. A small section of the IOHK engineering team were interested to find out if they could demonstrate that it would be possible to create a lightweight Cardano wallet with all the features of Daedalus but that was easy to use and fast to set up. Whilst we are improving Daedalus synchronization speeds all the time, notably in the recent 1.3 release, we wanted to see if we could build something fast for Ada users who might not require the full features of Daedalus, or might not have the bandwidth or machine requirements to easily run Daedalus.

Therefore, investigating whether it would be possible to build a wallet where the user did not have to download the whole blockchain – and could run in a browser or on a mobile device – was worth the effort of a small dedicated team.

To build a wallet like this, we would need to prove that we could safely and securely store private keys and execute client-side cryptographic operations in the browser. In tandem, we would need to communicate with the Cardano nodes to provide users with their current UTxO state. If this could be accomplished, it would be no mean feat, hence the name Icarus – from the beginning we knew we would be flying close to the sun.

The team set out in at the beginning of March with ambitious goals to see if, within a month, we could build a skeleton Chrome extension application and verify that Cardano cryptography could be run in the browser using WebAssembly compiled from Rust. The Rust library of Cardano primitives has been developed by Vincent Hanquez and Nicolas Di Prima, IOHK Specialised Cryptographic Engineers, and has already been used for the paper wallet certificate feature in Daedalus.

To build this Chrome extension, we would need to successfully demonstrate we could import and track a wallet balance. Of course, we would have to do all this without sacrificing the IOHK engineering principles of quality and security.

The demo at the end of March went well and produced a functional prototype that we could develop. Once each demo had been given, the wider IOHK engineering team had a chance to review, critique and provide feedback about the design decisions the Icarus project team was taking, which proved invaluable to the process. After proof of concept 1, it was felt that good progress was being made and another month’s effort from the team would be worthwhile.

Proof of concept 2 was delivered in mid-April. The Rust engineers had spent the intervening time extending the Rust library to support the Cardano primitives for the creation, signing, and broadcast of transactions, and providing an API so that these could be run in the browser. On the application side, we wanted to see if we could reuse the UX/UI components of Daedalus to provide a smooth user experience. Luckily, the IOHK Daedalus development team has maintained a high-quality, portable UI framework for React, called React-Polymorph, which we found to be easily portable to the Chrome extension.

Proof of concept 3 in late May involved making Icarus fully interoperable with the Daedalus wallet. The team worked to develop a new Hierarchical Deterministic (HD) address scheme that Daedalus will use in future and will ensure ongoing compatibility. One important feature we built at this point was to allow the user to enter their Daedalus wallet recovery phrase in Icarus, and for their Ada in Daedalus to be transferred to the Icarus wallet. In effect, this allows users to retrieve their Ada without using the Daedalus wallet. We also optimised wallet restoration times. Finally, after only three months and three demo’s we had a fully functional prototype lightweight Cardano wallet!

Before we could ensure this was a reference implementation we could release to the community, we wanted to ensure that it performed at scale. This, along with some code clean-up, was the main task of the final proof of concept 4 in early June. We called upon the experience of Philipp Kant, in IOHK benchmarking, and Neil Davies, leading networking, and successfully conducted a series of rigorous stress and failover tests on the architecture.

The code base has been quality assured by Allied Testing, a leading quality assurance and testing company. We also engaged Kudelski Security, a cybersecurity consultancy, to perform a full security audit of the code – their report will be published soon.

emurgo trip
L-R: Nicolás Arqueros, Alan Verbner, Brian McKenna, Sebastien Guillemot

We knew that Emurgo, the organisation that supports new Cardano ventures, was interested in releasing the first implementation of Icarus to the community. To that end, we invited two Emurgo staff – Nicolás Arqueros, chief technology officer, and Sebastien Guillemot, technical manager – to Buenos Aires to meet lead Icarus developer Alan Verbner and his team in July. The goal of this trip was to see if the code could be understood and deployed by open source community members. Emurgo provided feedback on how we could make the reference implementation ready to release as a product and they wrote a technical specification for the code base. We are excited that

Emurgo
will soon be launching their implementation of Icarus, the Yoroi wallet, and look forward to seeing how they carry through their vision for the product.

In mid-July, Hayley McCool Smith, IOHK Product Marketing Manager, visited Emurgo at their offices in Tokyo. One of the purposes of the trip was to take part in a naming workshop which would help Emurgo bring their product to life. After spending a day working through a plethora of contenders that Emurgo had shortlisted, it was decided that “Yoroi” was the perfect fit. In Japanese, Yoroi means “great armour” and is a prominent example of the type of secure armament that Samurais would wear to protect themselves. With the name decided, it was up to the team to create a logo that would reflect a new lightweight wallet, while also incorporating the traditional Samurai meaning of the word.

emurgo tokyo
Emurgo team in Tokyo

The Rust library that was used to bring the Cardano cryptography into the browser has spawned another IOHK project, the Cardano Rust project. (This has been known as Project Prometheus internally.) IOHK will be releasing more information on this in due course. The Cardano Rust project will maintain the open source spirit of Icarus and further extend the toolbox of Rust modules. The project will be made available to the open source community to easily build high-quality applications using Cardano. The first product of the project will be a full command line interface wallet, which you can expect to see in September.

The segmented development team and rapid iteration approach to software development has worked well on Project Icarus and we will be employing this strategy again. We are happy that Ada holders will have the ability to store their Ada in the really cool Yoroi wallet and that developers have a high-quality reference implementation on which to base their own new light and mobile wallets for Cardano. The project has also given rise to Project Prometheus which is the natural evolution of the spirit of Icarus.

We feel that we have developed, in quite a short time, a very useful quality assured and security audited reference implementation for a lightweight Cardano wallet. We encourage the open source community to fork the Icarus code base, compile it, and maybe even build your own wallet for Cardano. We welcome contributions and hope that this effort will benefit the entire community.

This blog has been amended to update the name of the Cardano Rust project from Project Prometheus.

Artwork,
Creative Commons
Mike Beeple