Developing Cardano is no small feat. There is no other project that has ever been built to these parameters, combining peer reviewed cryptographic research with an implementation in highly secure Haskell code. This is not the copy and paste code seen in so many other blockchains. Instead, Cardano was designed with input from a large global team including leading experts and professors in the fields of computer programming languages, network design and cryptography. We are extremely proud of Cardano, which required a months-long meticulous and painstaking development process by our talented engineers. With that in mind, I’m pleased to report that we are finally reaching the end of development. The target launch date is September 29 and this is based on all current, known information. We had originally planned to launch by the end of August, so there have been a few additional weeks of development. The extra time was partly due to our team uncovering a few unexpected bugs which delayed testing of the overall network. It also took longer to set up Cardano’s internal test network than expected. But during those extra weeks, we have also been able to make enhancements to dramatically improve Cardano’s performance. One of the things engineers did to improve Cardano’s performance was to change the format of messages that are sent between nodes on the network. We upgraded our binary serialisation format from a custom version to one based on an open, common standard that means third parties, such as exchanges, will find it easier to build their own nodes, and our system becomes more transparent.
In recent weeks, engineers also made improvements to the network layer, rewriting code to make it run faster. The system is more stable under load and the number of transactions per second is higher. We are further improving the transaction speeds of the network and in the coming months after release will demonstrate our results. These two improvements took a few weeks to fully implement and test.
We have now added additional protection against DDoS, or distributed denial of service, attacks. The network’s core nodes have been placed behind firewalls, so they are not accessible from the public internet. This gives us some protection against this type of attack, because potential attackers can’t reach Cardano’s core nodes. To do this, we surrounded the core nodes with proxies, called relay nodes, which by contrast are visible to the internet. As their name suggests, these nodes relay messages to the core nodes. Even if there was an attack, the blockchain would be protected because the core nodes are not directly exposed.
We have also introduced improvements to Cardano’s delegation scheme, which keeps the network running even if its end users are not online, to strengthen it against attacks to its signature scheme. This provides an element of future-proofing by preventing attackers from stealing funds if new attacks against its signature scheme are discovered in the future. Cardano is based on proof of stake, so our solution is that Ada holders will have separate public-private keys for their coins and for their stake and the public key for the coins will not be published. This is the first step of a long term strategy to harden Ouroboros against quantum computers, a process which will require new research.
While all this work was going on during the past few weeks, the team has done a lot more testing, which is always good. We found bugs, which we fixed, and the testing gave us a better assurance of quality.
Recently, IOHK research – our Ouroboros and SCRAPE papers – were also accepted to two major conferences, ACNS in Japan, and Crypto 2017 in the US, and we were very proud our work has been recognised by the academic community and has been peer reviewed. A major exchange that has agreed to list Ada at launch has also been integrating with Cardano’s network. As a result, we have been adding some recommended features and minor changes.
All this development work has meant that Cardano’s code has changed, sometimes significantly. That means everything has to be retested. You can’t simply update code and assume that everything will be fine. The process of releasing a new version of the software takes a couple of weeks because that is how long it takes to test, and fix bugs and carry out tasks such as preparing new installers.
Development has been a lengthy process but we are now very pleased to share a detailed plan showing the launch countdown. Cardano is a unique and very special product and we look forward to passing it into your hands.
I’m delighted to announce the release of Why Cardano, a document explaining the philosophy behind the design and development of Cardano. Publishing this is a key milestone for the project and I hope it helps with explaining why we are building Cardano. The document is fully translated to Japanese, Chinese and Korean, also join the community by visiting Cardano community social channels via cardanohub.org.
Cardano is a project that began in 2015 as an effort to change the way cryptocurrencies are designed and developed. The overall focus beyond a particular set of innovations is to provide a more balanced and sustainable ecosystem that better accounts for the needs of its users as well as other systems seeking integration.
In the spirit of many open source projects, Cardano did not begin with a comprehensive roadmap or even an authoritative white paper. Rather it embraced a collection of design principles, engineering best practices and avenues for exploration. These include the following:
- Separation of accounting and computation into different layers
- Implementation of core components in highly modular functional code
- Small groups of academics and developers competing with peer reviewed research
- Heavy use of interdisciplinary teams including early use of InfoSec experts
- Fast iteration between white papers, implementation and new research required to correct issues discovered during review
- Building in the ability to upgrade post-deployed systems without destroying the network
- Development of a decentralized funding mechanism for future work
- A long-term view on improving the design of cryptocurrencies so they can work on mobile devices with a reasonable and secure user experience
- Bringing stakeholders closer to the operations and maintenance of their cryptocurrency
- Acknowledging the need to account for multiple assets in the same ledger
- Abstracting transactions to include optional metadata in order to better conform to the needs of legacy systems
- Learning from the nearly 1,000 altcoins by embracing features that make sense
- Adopt a standards-driven process inspired by the Internet Engineering Task Force using a dedicated foundation to lock down the final protocol design
- Explore the social elements of commerce
- Find a healthy middle ground for regulators to interact with commerce without compromising some core principles inherited from Bitcoin
From this unstructured set of ideas, the principals working on Cardano began both to explore cryptocurrency literature and to build a toolset of abstractions. The output of this research is IOHK’s extensive library of papers, numerous survey results such as this recent scripting language overview as well as an Ontology of Smart Contracts, and the Scorex project. Lessons yielded an appreciation for the cryptocurrency industry’s unusual and at times counterproductive growth.
Thoughts on an ontology of smart contracts
6 March 2017 6 mins read
The concept of smart contracts has grown considerably since the birth of Ethereum. We've seen an explosion of interdisciplinary research and experimentation bundling legal, social, economic, cryptographic and even philosophical concerns into a rather strange milieu of tokenized intellect. Yet despite this digital cambrian explosion of thought, there seems to be a lack of a unified ontology for smart contracts. What exactly is an ontology? Eschewing the philosophical sense of the word, an ontology is simply a framework for connecting concepts or groups alongside their properties to the relationships between them. It's a fundamental word that generally is the attempt at bedrock for a topic. For example, it's meaningful to discuss the ontology of democracy or the ontology of mathematics.
Why would one want to develop an ontology for smart contracts? What is gained from this exercise? Is it mostly an academic exercise or is there a prescriptive value to it? I suppose there are more questions to glean, but let's take a stab at the why.
Smart contracts are essentially two concepts mashed together. One is the notion of software. Cold, austere code that does as it is written and executes for the world to see. The other is the idea of an agreement between parties. Both have semantical demands that humans have traditionally had issues with and both have connections to worlds beyond the scope in which the contract lives.
Much of the focus of our current platforms, such as Ethereum, is on performance or security, yet abstracting to a more ontological viewpoint, one ought to ask about semantics and scope.
From a semantical perspective, we are trying to establish what the authors and users of smart contracts believe to be the purpose of the contract. Here we have consent, potential for non est factum style circumstances, a hierarchy of enforceability and other factors that have challenged contract law. What about cultural and linguistic barriers? Ambiguity is also king in this land.
Where normal contracts tend to pragmatically bind to a particular jurisdiction and set of interpretations with the escape hatch of arbitration or courts to parse purposeful ambiguity, decentralized machines have no such luxury. For better or worse, there is a pipeline with smart contracts that amplifies the semantical gap and then encapsulates the extracted consensus into code that again suffers from its own gap (Loi Luu demonstrated this recently using Oyente).
Then these structures presume dominion over something of value. Whether this dominion be data, tokens or markers that represent real life commitments or things such as deeds or titles. For the last category, like software giving recommendations to act on something in physical world, the program can tell one what to do, but someone has to do it.
So we have an object that combines software and agreements that has a deep semantic and scope concern, but one could add more dimensions. There is the question of establishing facts and events. The relationship with time. The levels of interpretation for any given agreement. Should everything be strictly speaking parsed by machines? Is there room for human judgement in this model (see Nick Szabo, Wet and dry code and this presentation)?
One could make a fair argument that one of the core pieces of complexity behind protocols like Ethereum is that it actually isn't just flirting with self-enforcing smart contracts. There are inherited notions from the Bitcoin ecosystem such as maximizing decentralization, maintaining a certain level of privacy, the use of a blockchain to order facts and events. Let's not even explore the native unit of account.
These concepts and utilities are fascinating, but contaminate attempts at a reasonable ontology that could be constructive. A less opinionated effort has come from the fintech world with both Christopher Clack's work on Smart Contract Templates and Willi Brammertz’s work on Project ACTUS. Here we don't need immutability or blockchains. The execution environment doesn't matter as much. It's more about consensus on intent and evaluation to optimize processes.
What about the relationship of smart contracts with other smart contracts? In the cryptocurrency space, we tend to be blockchain focused, yet this concept actually obfuscates that there are three data domains in a system that uses smart contracts.
The blockchain accounts for facts, events and value. There is a graph of smart contracts in relation to each other. Then there is a social graph of nodes or things that can interact with smart contracts. These are all incredibly different actors. Adding relays into the mix, one could even discuss the internet of smart contract systems.
Perhaps where an ontology could be most useful is on this last point. There seems to be economic value in marrying code to law for at least the purpose of standardization and efficiency, yet the hundreds of implicit assumptions and conditions upon which these systems are built need to be modelled explicitly for interoperability.
For example, if one takes a smart contract hosted on Rootstock and then via a relay communicates with a contract hosted on Ethereum and then connects to a data feed from a service such as Bloomberg offers, then what's the trust model? What assumptions has one made about the enforceability of this agreement, the actors who can influence it and the risk to the value contained? Like using dozens of software libraries with different licenses, one is creating a digital mess.
To wrap up some of my brief thoughts, I think we need to do the following. First, decouple smart contracts conceptually from blockchains and their associated principles. Second, come to grips with the semantic gap and also scope of enforcement. Third, model the relationships of smart contracts with each other, the actors who use them and related systems. Fourth, extract some patterns, standards and common use practices from already deployed contracts to see what we can infer. Finally, come up with better ways of making assumptions explicit.
The benefits of this approach seem to be making preparations for sorting out how one will design systems that host smart contracts and how such systems will relate to each other. There seems to be a profound lack of metadata for smart contracts floating around. Perhaps an ontology could provide a coherent way of labeling things?
Thanks for reading,
Professor Aggelos Kiayias joins IOHK as Chief Scientist
21 October 2016 4 mins read
Professor Aggelos Kiayias joins IOHK as Chief Scientist
Prof Kiayias is the pre-eminent academic in the field of blockchain security. He has produced pioneering work providing the rigorous analysis necessary to secure confidence in this emerging technology.
Blockchain technology has the potential to significantly reshape the future of finance, and Prof Kiayias is the leading researcher promoting and studying the science behind blockchain systems. In one project, Prof Kiayias led a team in Athens last year that designed the first e-voting system, where voters could verify that votes cast actually went to the intended candidate, without relying on a trusted system component.
Prof Kiayias produced a key paper proving fundamental properties of bitcoin blockchain and played a lead role in writing IOHK’s paper on the first provably secure Proof-of-Stake protocol, published in the IACR Cryptology ePrint Archive and available in the IOHK research library.
Prof Kiayias said that IOHK’s rigorous standards made it stand out among cryptocurrency companies.
“I am very happy to engage with a team of very enthusiastic researchers in the area of blockchain systems,” he said.
“While other companies may consider taking shortcuts or focus on just engineering their products, IOHK makes long-term commitments in building basic tools that are available to the community as a whole and in advancing the science behind blockchain systems.”
Charles Hoskinson, chief executive and co-founder of IOHK, said: “Professor Kiayas is one of the most rigorous and creative cryptographers working in the cryptocurrency space, with a long pedigree of accomplishments from the GKL15 model to the first provably secure Proof-of-Stake algorithm.
“It’s a tremendous honor to have Aggelos on board as our Chief Scientist to help IOHK navigate the complex, yet always sublime world of cryptography. We look forward to the results this collaboration will bring as well as the great papers that will undoubtedly follow.”
Prof Aggelos Kiayias is the Chair in Cyber Security and Privacy at the University of Edinburgh. His research interests are in computer security, information security, applied cryptography and foundations of cryptography with a particular emphasis in blockchain technologies and distributed systems, e-voting and secure multiparty protocols as well as privacy and identity management. He joins IOHK as chief scientist through a long-term consulting agreement between IOHK and the University of Edinburgh, UK, where he is based and continues to do research and teach courses in cyber security and cryptography. Prof Kiayias is also Professor in Residence (gratis) at the University of Connecticut, USA, and Associate Professor of Cryptography and Security (on leave) at the National and Kapodistrian University of Athens, Greece.
Prof Kiayias’s cyber security research over the years has been funded by the Horizon 2020 programme (EU), the European Research Council (EU), the General Secretariat for Research and Technology (Greece), the National Science Foundation (USA), the Department of Homeland Security (USA), and the National Institute of Standards and Technology (USA). He has received an ERC Starting Grant, a Marie Curie fellowship, an NSF Career Award, and a Fulbright Fellowship. He holds a Ph.D. from the City University of New York and he is a graduate of the Department of Mathematics at the University of Athens. He has more than 100 publications in journals and conference proceedings in the area.
He currently serves as the program chair of the Financial Cryptography and Data Security 2017 conference.
Ethereum Classic: An Update
9 September 2016 8 mins read
I wanted to draft a brief update on IOHK's efforts on Ethereum Classic (ETC). We've had the opportunity to schedule more than three dozen meetings with developers, community managers and academic institutions. We've also managed to have several long discussions with several of the community groups supporting ETC to get a better sense of commitments, goals and philosophy. Overall, it's been a really fun experience getting to know a completely decentralized philosophical movement. It's also been illuminating to parse the challenges ahead for the fragile movement as it charts its own path forward. I'll break the report down into what we learned and what we are going to do.
What We Learned
Carlo Vicari and I have been trying to map out the total ETC community and also get some metadata about who they are (vocation, age, geography, interests...) so we can better understand the core constituencies. We will publish some preliminary stats sometime next week, but as a rough summary there are currently several meetup groups, a telegram group, a reddit, several Chinese specific hubs, a slack with over 1,000 members and a few other lingering groups.
Daily activity is growing and there is interest in more formal structure. With respect to developers, there are about a dozen people with development skills and knowledge of the EVM and solidity in the developer channel. They have been holding pretty deep discussions about potential directions and roadmaps. The biggest topics are currently pivoting consensus to PoW without the difficult bomb, new monetary policy and also safer smart contracts.
There is also interest in forming a pool of capital to pay for development efforts ranging from core infrastructure to DApps on top of the system. I haven't taken a position on this effort because we still need to address some governance and legal questions. Regardless of whether this pool materializes, IOHK's commitment of three full time developers will be funded solely by IOHK.
It seems that the price and trading volume of ETC has held relatively stable despite the virtual sword of damocles that is the DAO hacker and RHG funds. It seems that there is enough community interest in ETC to keep liquidity. I do think there will be tremendous volatility ahead and it's going to be impossible to predict when black swans are going to land in our laps, but I suppose that's what makes it fun?
After the initial conversations and analysis, we have determined the following serious deficits with ETC:
- There isn't an official or reliable channel of information about the events of the ecosystem or commitments of various actors. This reality has lead to FUD, impersonations and attempts at market manipulation in the absence of clarity.
- The roadmap of ETC needs to include at a minimum an emphasis on safety, sustainability and stability. There is a strong desire amongst the ETC community members we had discussions with to focus on reliable, high assurance applications that run on a network with proven fundamentals. Effectively, this needs to be the antithesis of move fast and break things.
- There is a desire amongst several well capitalized actors to donate capital to a pool to fund the growth of ETC. This desire has been complicated by the lack of a clear governance structure that will avoid fraud or misuse of funds. Furthermore an open pool would allow funds to potentially become tainted by RHG or Dao hacker donating funds to it. While code is law covers the protocol level use of funds, it does not shield actors from the legal realities of their actions. It is unclear how these funds should be treated or if accepting them would constitute a crime.
- The media is uncertain how to report on ETC outside of a referential curiosity to ethereum itself . There needs to be a re-branding and media strategy to ensure new users enter the ecosystem with a clear understanding of what ETC is about and how it differs from ETH.
- Concepts like the replay attack and also new potential technology that could be adopted are not fully understood by ETC community members or general developers. There needs to be actors dedicated to education and explanation.
- The Ethereum Foundation owns the Ethereum trademark. Further use of this branding could provoke a trademark infringement lawsuit to companies using the Ethereum brand and name. This complicates the formation of a centralized governance entity or steering committee if it chooses to use ethereum classic as its name. It also complicates business commitments to building on the ETC chain.
Thus IOHK is in the process of doing the following:
- We have interviewed several community manager candidates and will make our final selection sometime next week. He or she will be responsible for assisting meetup group founders, managing social media channels, broadcasting accurate information, combating FUD, collecting feedback from the ETC community and dealing with media entities. My hope is this position will be defined by its interactions with the ETC community and give us a starting point for timely and credible information at the very least.
- IOHK is going to subsidize an educator to produce content on ETC ranging from the replay attack to new proposals suggested in various roadmaps. We have one candidate in mind and are finalizing the contract and duration of the relationship. All content will be released under a creative commons license and our hope is to again let this role be community driven.
- IOHK has had numerous discussions with academic partners about the consensus algorithm of ETC and also the smart contract model. We would like to see if the EVM can be improved to be more secure and that Typescript and Purescript could be used as ETC's smart contract languages representing both a functional and imperative approach to development that maps nicely onto the skillsets of existing developers. We are seeing what types of partnerships are possible in the next few months and will provide an update.
- We've also spent quite a bit of time looking at Smart contract languages on the horizon. There are some excellent ideas coming from Synereo and Juno's Hopper. IOHK has entered into a partnership with Kent University to begin an analysis of Transaction Languages used in cryptocurrencies. We will have a survey report available sometime in Q4 of 2016. This report will form the basis of our organization's understanding of the interplay of smart contracts in cryptocurrencies. Once available we will release it to the general public as a whitepaper.
- We have decided that Scorex 2 will make a good base to build our ETC Main Client (Read Alex's First Blog on It). The core is going through a massive refactoring that will be finished sometime this month. From this point, we will retain a scala specific team (our three developer commitment) to fork Scorex 2 and build a full ETC Node including a wallet with GUI. The architecture of Scorex should allow for much faster iterative improvements and also a great opportunity to test our new blockchain specific database IODB .
- With respect to the developer hires in particular, we have taken quite a few resumes already, but also want to make the process open to the general public. Our new community manager will post the job ad on the ETC reddit once he's been hired. I expect the first developer to be announced sometime in September. Quality scala developers with the requisite skills to make meaningful contributions to Ethereum are rare and require careful vetting.
- With respect to a technological steering committee to guide the roadmap process, we are proposing the formation of a federated group tentatively called the smart contract engineering taskforce (after the IETF). Ideally we could develop an RFC process to propose improvement proposals from the community without the need for a formal, centralized entity. We'd love to see this form as a DAO. There could be two tracks covering changes requiring forks and changes that are iterative in nature. We will start the discussion about this group sometime in early October.
- IOHK cannot resolve the trademark issue, but will make a commitment to not use the Ethereum brand or name in its repos or company assets. This said, we would like to see some form of bilateral resolution to this situation. It seems pyrrhic to seek trademark enforcement on a decentralized movement. We also understand the confusion this issue is causing the general public and developers.