Last night, we had our Developers meetup in London. We had fantastic, knowledgeable presenters from IOHK and a great turnout from the community. Special thanks to the London Blockchain Labs, LSE Blockchain Society and UCL for the support and providing a great venue!
Presenters:
- Duncan Coutts (Director of Engineering)
- Neil Davies (System Performance Scientist)
- Philipp Kant (Director of Formal Methods)
- Darko Mijic (Cross-Platform Developer, Daedalus)
Details on these team members can be found here.
We filmed the presentation and the Q&A session, so this will be posted at a later date.
In the meantime, I tried my best to take some notes for those of you who couldnât attend. Disclaimer: I am not a developer or come from a technical-background, so hopefully I am able to articulate the material properly. 
Duncanâs Presentation: Insights into Cardano Development: Past, Present and Future
The Past:
Duncan started with the brief history timeline of Cardano. From September 2016 when the first git commit was made, to September 2017 when the mainnet was released, to present day where we are at the start of regular rolling releases.
Next, the role of exchanges was explained. Exchanges are crucial and important for cryptocurrencies as there is no value in crypto without the ability to trade. At the time of the mainnet launch, there was one exchange. Today, there are approximately a dozen with significant Ada volume. And the coming new wallet API 1.2 is better designed for exchanges and therefore, we can expect to have more integrate the Daedalus wallet.
An added note from Neil is that because there was no existing specification of how wallets are to be used with exchanges (since it hadnât been done), it was an interesting learning curve building the system. Many times, exchange didnât behave how youâd expect them to nor did they interact with the API in the presumed way.
The Present:
This brings us to the âpresentâ, where the IOHK devs team can look at the lessons learned from deploying the wallet and mainnet. The positive is that they achieved excellent core system stability, meaning there has been no downtime of the core system.
But in hindsight, they learned that:
- performance requirements need to be clearly understood
- performance engineering needs to be done much earlier
- distributed concurrency and networking are hard
The outcome of this retrospection is that hard problems need to be solved with greater formality!
Another lesson example was the wallet backend. With Daedalus, there is a front and backend. The backend posed a few problems, mainly unobserved by the end-user, but rather with the exchanges. The Daedalus wallet backend had to cope with a sudden large increase in the volume of transactions. But this led to a rewriting of the wallet backend data layer from scratch and they now have a 30-page semi-formal specification.
Another topic covered in this section was the âRobustness and Resilience in Cardano SLâ. The goal is to make a robust system that can maintain value, that people can trust, that people will want to place their assets into. The development team worked to create a system that was also âdesigned to surviveâ. Neil discussed how the Cardano system can actually survive outcomes like an Mid-Atlantic earthquake that cut all fibres, or a ring of fire wiping out data centres in various countries. The blockchain is designed with the ability to be shutdown and restart, should it be required. All of this sounds of âover-providedâ but this is the sort of robust system (which takes into account risks/hazards and have mitigation plans in place) that is required to replace existing systems.
Here, they also touched on benchmark testing, a method used to make their system even better. Looking at aspects like DDOS or the decision to sidestep DNS which proved to be a major risk (ie. think of the recent MyEtherWallet hack).
Finally, Duncan and Neil discussed semi-formal software development. This is the âmiddle groundâ between the less formal and the more traditional, slow formal approach. This approach is still based on precise, mathematical notation and system but with the aim of a one-page spec. By aiming for a one-pager, they are forced to think clearly and to simplify as much as possible. Duncanâs âbasic modelâ fits on one page (and this applies for all cryptos, not Cardano-specific) and the point of creating this is that anyone with a mathematics or computer science background could read this, build a solid intuition and understand what is necessary. This also allows for subsequent discussions, in this case between the researchers and academics who are not Haskell programmers and the developers who implement the code.
The Future
Primarily, the smart contract platforms were presented. Smart contracts being programs or application that make use of blockchain. In Cardanoâs case, two approaches are being pursued.
i) The âlegacyâ or traditional approach (ie. Eth): K-EVM and IELE
ii) and a new, radical approach: Plutus, Plutus Core, Marlowe
K-EVM corresponds with EVM but with a higher degree of confidence and IELE is derivative of that, that also fixes glaring problems of EVM while still being compatible. Plutus is very similar to Haskell, Plutus Core was presented as a intermediate language, equivalent to EVM bytecodes, and Marlowe is a DSL specifically for financial contracts.
Other items in the works were:
- full decentralization with stake pools
- hardware, light and mobile wallets
- SL / CL split with sidechains
- multi-currency ledger
- smart contracts with IELE, Plutus, Marlowe
- new higher-assurance Ouroboros Praos
- comprehensive new networking layer based on RINA
With this last point, they discussed why the current internet and TCP/IP is not fit for purpose.
DOWNLOAD PRESENTATION SLIDES >
Part 2 for the Q&Aâs from the evening can be found here.