Jekyll2022-06-24T15:46:14+00:00https://meld-labs.github.io/technical/feed.xmlMELD Technical JournalWe write technical blogs, updates, notes and post relevant resources here. This includes MELD core works and open-source contributions.Akamon β White Paper v12022-06-23T17:00:00+00:002022-06-23T17:00:00+00:00https://meld-labs.github.io/technical/reports/2022/06/23/akamon-beta-v1-paper<h1 id="abstract">Abstract</h1>
<p>This paper presents the current state of Akamon β, a native bridge between Cardano and Polygon. The objective is to to leverage both chains’ efficient infrastructure to bridge and use native assets cross chains. Akamon aims to be a community-driven bridge open for everyone, emphasizing decentralization and trustless custody. Nevertheless, in the second version, we have to start somewhere in-between and continue to push for decentralization in later versions. The goal is to make iterative improvements to collect experiences along the way. For instance, an early semi-centralized testnet brings us practical UX, infrastructure, economics, and operations foundations to focus more on decentralization from γ.</p>
<embed src="https://meld-labs.github.io/technical/assets/akamon-beta-v1.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<h1 id="conclusion">Conclusion</h1>
<p>We focus on the high-level descriptions of the current state of Akamon β in the first two white paper versions.
We expect to cover many more depths on the third version to be published by the end of July 2022 as β hits the mainnet.</p>AbstractAkamon β White Paper v02022-06-02T17:00:00+00:002022-06-02T17:00:00+00:00https://meld-labs.github.io/technical/reports/2022/06/02/akamon-beta-v0-paper<h1 id="abstract">Abstract</h1>
<p>This paper presents the current state of Akamon β, a native bridge between Cardano and Polygon. The objective is to leverage both chains’ efficient infrastructure to bridge native assets between them. Akamon aims to be a community-driven bridge open for everyone, emphasizing decentralization and trustless custody. Nevertheless, in the second version, we have to start somewhere in-between and continue to push for decentralization in later versions. The goal is to make iterative improvements to collect experiences along the way. For instance, an early semi-centralized testnet brings us practical UX, infrastructure, economics, and operations foundations to focus more on decentralization from γ. We will also cover many more depths on the second paper version to be published on June 20th as β hits the public testnets.</p>
<embed src="https://meld-labs.github.io/technical/assets/akamon-beta-v0.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<h1 id="conclusion">Conclusion</h1>
<p>We focus on the high-level descriptions of the current state of Akamon β in this first white paper version. We expect to cover many more depths on the second version to be published on June 20th as β hits the public testnets.</p>AbstractTechnical Report 2022/05/152022-05-14T17:00:00+00:002022-05-14T17:00:00+00:00https://meld-labs.github.io/technical/reports/2022/05/14/technical-report<p>Welcome to the MELD May 2022 technical report for the progress of the last 30 days!</p>
<p>The main focus has been completing the first version of Akamon Alpha, integrating it with MELDapp, and being ready for a public release.</p>
<h2 id="akamon">Akamon</h2>
<h3 id="alpha">Alpha</h3>
<p><img src="/technical/assets/akamon.png" alt="Akamon Alpha Banner" /></p>
<p>Akamon α is the first design iteration among the many we develop. We design the bridge iteratively to focus on a new fundamental concept with each iteration. α focuses on setting up the foundation for the later versions. We also aim to collect UX, infrastructure, and operations experience through it to have more space for decentralization designs in the later iterations. β expects to semi-decentralize the bridge, γ promises to bring more networks to the table, with δ seeks a fuller decentralization design.</p>
<p>The foundation for all iterations is to wrap assets between the chains. For example, an ADA round trip can be seen below.</p>
<p><img src="/technical/assets/ada-roundtrip.png" alt="Akamon ADA Roundtrip" /></p>
<p>Users first send ADA or mMATIC to an on-chain script to initiate a request. Sending ADA is to mint mADA on Polygon. Sending mMATIC is to burn them on Cardano to get back MATIC on Polygon. Confirmation then happens when validators sign to confirm the request. Once enough signatures are gathered, the users receive tokens on the bridge’s other end. The confirmation process should evolve with each iteration, from centralized (one signature) to fully decentralized (community nodes).</p>
<p>The bridge nodes should also stake locked tokens to generate additional revenues. This incentivization is key to node operators and users, implying that the more traffic there is, the lower transaction fees.</p>
<p>Due to the iterative nature of the process, it is also essential to build migration frameworks to transition from one iteration to another seamlessly. This process includes both data and assets migration, which is not trivial to do right.</p>
<h3 id="public-testnet-launch">Public Testnet Launch!</h3>
<p>We tested the finalized mADA and mMATIC tokens and their integration in MELDapp on the Cardano public testnet and Polygon Mumbai for over two weeks. While there are still many improvements to be made, we have decided it is time to release the bridge to the public. A testnet deployment avoids most risks for the people involved while bringing valuable UX, infrastructure, operations, and community management experience and feedback.</p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/DWMnRYDqULw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
<p>We are finalizing the deployment and marketing details to perform the public testnet launch on May 16th 2022!</p>
<h3 id="beta">Beta</h3>
<p>We do not intend to release the centralized α to the mainnet. We have been designing a more distributed and decentralized β in parallel. The main goal of an α testnet launch is to collect UX, infrastructure, operations, and community management experiences to have more focus space for decentralization later on.</p>
<p>User needs and how they interact with the bridge should stay the same regardless of its underlying architecture. One should not sacrifice UX to be a little bit more decentralized if that is quantifiable in the first place.</p>
<p>We have been writing the β paper with actual technical discussions on the economics model, governance model, and contract designs leading towards decentralization. The paper will be released at the end of May. A β testnet launch with more bridge partners will follow suit on June 5th 2022.</p>
<h2 id="upcoming-products">Upcoming Products</h2>
<p><img src="/technical/assets/roadmap.png" alt="Roadmap" /></p>
<p>We continue to design the upcoming products to meet our aggressive roadmap. These include protocol fees (from Akamon revenues), MELD token utility, variable staking, governance, migration, and lending. Everything leading to governance will be demonstrated in a dedicated white paper at the end of July. Lending is trickier as we want to develop a sustainable yet innovative model to compete with the existing ones on all chains. We will publish the first dedicated white paper for lending at the end of August.</p>
<p>We have been targeting Cardano’s upcoming Vasil hard fork that brings many improvements to smart contract designs for these upcoming products. We have been slowly but surely working on many Plutus V2 tooling in anticipation. Once Akamon is more stable, we would put more effort into these works and hopefully open-source more tools to the ecosystem.</p>
<p>With Akamon in hand, we have also been studying more ecosystems outside of Cardano. For instance, we consider adding Avalanche and Nervo’s support to later versions of Akamon. Together with our Polygon works thus far, these efforts bring interoperability options and experience to make MELD products cross chains.</p>
<p>Finally, as we push these products closer to mainnet, we will start publishing security tooling and analysis. Both MELD and Hachi have been moving closer to a product-driven direction from a more research-driven one. The key is defining user-driven products and then researching and developing them.</p>
<h2 id="conclusion">Conclusion</h2>
<p>We cannot wait to release Akamon Alpha to the public, engage users and gather tons of experience from it. We then look forward to the upcoming monthly launches of the white papers and products. It is an exciting time to build!</p>Welcome to the MELD May 2022 technical report for the progress of the last 30 days!Akamon α White Paper2022-05-03T17:00:00+00:002022-05-03T17:00:00+00:00https://meld-labs.github.io/technical/reports/2022/05/03/akamon-alpha-paper<h1 id="abstract">Abstract</h1>
<p>This paper presents Akamon α, a native bridge between Cardano and Polygon. The objective is to leverage both chains’ efficient infrastructure to bridge native assets between them. Akamon aims to be a community- driven bridge open for everyone, emphasizing decentralization and trust-less custody. Nevertheless, we have to stay centralized in the first testnet launch and semi-decentralized in the upcoming launches towards the end of 2022. The goal is to make iterative improvements to collect experiences along the way. For instance, an early centralized testnet brings us practical UX, infrastructure, and operations foundations for us to focus on decentralization later on. We will propose our road to decentralization in an Akamon β paper to be released end of May. A β testnet launch will follow suit on June 5th 2022.</p>
<embed src="https://meld-labs.github.io/technical/assets/akamon.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<h1 id="conclusion">Conclusion</h1>
<p>This α paper introduces all the components one may need to build a bridge between Cardano and Polygon. The design is intentionally centralized first to build a foundation for UX, infrastructure, and operations. Decentralization works have been done in parallel and will be introduced in a β paper at the end of May 2022. Blockchain interoperability is a relatively new field so much more innovation is still awaiting. We expect to improve many contract designs with the upcoming Cardano hard fork. Off-chain infrastructure and tooling on all ecosystems can only get better with time as well.</p>AbstractTechnical Report 2022/04/152022-04-14T17:00:00+00:002022-04-14T17:00:00+00:00https://meld-labs.github.io/technical/reports/2022/04/14/technical-report<p><img src="/technical/assets/roadmap.png" alt="Roadmap" /></p>
<p>Welcome to the second MELD technical report of 2022 for the progress of the last 45 days!</p>
<p>We have spent much effort researching innovative ideas for our DeFi products and governance system, experimenting with Plutus v2 designs with CIP 31/32/33, developing Akamon the bridge, polishing our UX research, infrastructure and code bases. The vision is to design unique dApp products for the Babbage era and be ready as early as possible when the Vasil hardfork hits. Until then, Akamon will be the first product we focus on launching.</p>
<h2 id="akamon-previously-adamatic">Akamon (Previously ADAmatic)</h2>
<p><img src="/technical/assets/akamon-ui-teaser.png" alt="Akamon UI Teaser" /></p>
<p>We have been working on two different versions of the bridge, an alpha without smart contracts and a beta with them. We expect to launch the alpha on testnet on May 5th and the beta on testnet on June 5th. After two months of both security and UX testing on the testnet, we will launch the first version of the bridge on mainnet on July 5th.</p>
<p>In December, we will launch a second version with superior designs built on top of the Vasil hard fork to testnet. We also aim to support native wrapping for more networks by then. Although design work has started, we need to be more patient for better Plutus v2 tooling for prototyping and verification.</p>
<p>Another critical line of work is to do security research with Hachi on both Cardano and blockchain bridges. Most brutal hacks in crypto thus far are on bridges, so we cannot take this lightly. A network’s on-chain is another network’s off-chain. It is non-trivial to have tight consensus and scalability when dealing with multiple networks. For now, we are surveying common bridges exploits and vulnerabilities to define security standards and checks for Akamon. The goal is to specify the bridge formally and write machine proofs for as many properties as possible.</p>
<p>Why Akamon again? The goal is to improve capital efficiency and token choices from different networks for the MELD protocol and the broader DeFi ecosystem. Our core product aims to bridge crypto and fiat and decentralise the process as much as possible. It makes much sense to extend the reach in the crypto world while making sure tight standards are met throughout the whole flow.</p>
<p>More information will be covered in the first public white paper and teaser video to be released this April 30th. Stay tuned!</p>
<h2 id="meld-lending">MELD Lending</h2>
<p>We have been spending a significant amount of effort on designing a suite of DeFi protocols on top of our lending foundation. Crypto-to-crypto has been more or less saturated recently, so we cannot simply develop an Aave or Anchor clone on Cardano. Instead, we have explored new ways to utilise smart contracts to enable under-collateralised loans. We have been working on diverse ideas ranging from a credit market with gamification, and asset management protocol, all the way to a brand new DeFi standard on UTxO that allows under-collateralised loans that do not leave the contracts that support it. We also have fresh ideas for new DeFi protocols that we may develop ourselves for the standard.</p>
<p>Given the innovative and experimental nature of the ideas, we still need much more time to formalise, simulate, and prototype them on the blockchain. Given their ambition and complexity, we would need all the new features and optimisations from the Vasil hardfork to pull them off. We will release the first white paper and teaser video this September. Hang tight!</p>
<p>We have been working hard on preparations for the fiat integrations, especially concerning legal and operations. We expect to release the first public white paper and teaser video on crypto-to-fiat this December, with a testnet launch planned for February 2023. Similar centralised services have been progressing well lately, making us even more determined to push for more decentralised solutions. The non-profit MELD Foundation is being set up for that exact reason.</p>
<h2 id="cardano">Cardano</h2>
<p>Since the last technical update, we have had two workshops with the Plutus Apps team.</p>
<p>The first one is scaling PAB, especially the chain index, which is still slow and resource-intensive. Previously, we were building our own <code class="language-plaintext highlighter-rouge">meld-index</code> on top of <code class="language-plaintext highlighter-rouge">plutus-chain-index-core</code> to serve chain data to the MELDapp. However, things get verbose every time we want to extend <code class="language-plaintext highlighter-rouge">meld-index</code> and build new solutions like <code class="language-plaintext highlighter-rouge">akamon-index</code>, <code class="language-plaintext highlighter-rouge">quant-index</code>, <code class="language-plaintext highlighter-rouge">hachi-index</code>, and more. Therefore, we have been building a rather opinionated yet assertive <code class="language-plaintext highlighter-rouge">cardano-index</code> framework to replace <code class="language-plaintext highlighter-rouge">plutus-chain-index-core</code> so everyone is only a few modules away from having a solid index syncing to PostgreSQL with builtin rollback handling. The key is to factor out the syncing framework, so dApp developers only need to define their data types and business logic in the few extra modules.</p>
<p>The second workshop is on our <code class="language-plaintext highlighter-rouge">dapp-starter</code> template with full testnet deployment and Nami integration. Educational resources like the Plutus Pioneer Program have not covered many infrastructure and off-chain topics, making it hard for new developers to deploy dApps and integrate them with external wallets. We also desire a tight template for the many smart contracts we are developing and a rich playground of diverse samples to experiment with new tooling (MELD and Hachi’s!) and ideas. It has proved very helpful to our interns thus far.</p>
<p>Our tooling suite also contains <code class="language-plaintext highlighter-rouge">cardano-api-extra</code> and <code class="language-plaintext highlighter-rouge">cardano-tx-builder</code> – lightweight and low-level API for extra Cardano functionalities and building transactions. While <code class="language-plaintext highlighter-rouge">cardano-api-extra</code> is utilised by several, mainly off-chain codebases as a low-level API, <code class="language-plaintext highlighter-rouge">cardano-tx-builder</code> aims to provide a low-level API to build transactions and a webserver to do so over HTTP. Our main goal is to replace the currently bloated PAB setup with a leaner one of <code class="language-plaintext highlighter-rouge">cardano-index</code> and <code class="language-plaintext highlighter-rouge">cardano-tx-builder</code>.</p>
<p>Staying lean (depending directly on <code class="language-plaintext highlighter-rouge">cardano-api</code>, <code class="language-plaintext highlighter-rouge">cardano-ledger</code>, and <code class="language-plaintext highlighter-rouge">plutus</code>) promises a faster Plutus V2 integration process. We have been designing many dApps with CIP 31/32/33 in mind and want to prototype them as soon as possible. We have compiled Plutus V2 validator scripts with CIP 31/32/33 using the latest <code class="language-plaintext highlighter-rouge">plutus</code> and <code class="language-plaintext highlighter-rouge">cardano-ledger</code> works. However, we still need to be more patient for <code class="language-plaintext highlighter-rouge">cardano-node</code> and <code class="language-plaintext highlighter-rouge">plutus-apps</code> to catch up and write better testing frameworks ourselves. One may follow these threads if interested in Plutus V2 integrations:</p>
<ul>
<li><a href="https://github.com/input-output-hk/cardano-node/issues/3739">input-output-hk/cardano-node#3739</a>.</li>
<li><a href="https://github.com/MELD-labs/plutus-apps/pull/11">MELD-labs/plutus-apps#11</a>.</li>
</ul>
<p>Once both Akamon and Plutus V2 integration get stable enough, we would love to explore more ideas like Hydra integration. We would also fancy open-sourcing these generic toolsets to the community once they are mature enough.</p>
<p>In conclusion, we have been anticipating an exciting Vasil hardfork and designing unique dApps accordingly. While developer experience, recruitment, and training for Cardano works are still challenging, we have been recording gradual progress as we build a more vital workforce on Cardano.</p>
<h2 id="hachi">Hachi</h2>
<p>As per the last report, Hachi has focused on practical tooling for dApp developers over pure research like in the early days. We have made several improvements to our Plutus transpilers, symbolic execution engine, concolic execution engine, fuzzers, and other helper tools. A Hachi API and an infrastructure to host it have also been the central focus to improve the interface between dApp developers and Hachi’s analysis stack. The goal is to build a developer-friendly API to automatically verify dApp’s properties and find bugs in Plutus scripts. While much progress has been made, the project is still non-trivial and would require at least another quarter to reach a public alpha.</p>
<p>Recently, MELD has joined hands with Hachi to do security research relevant to the Akamon bridge. We cannot wait to specify the bridge formally and automatically verify it with Hachi API – the gateway to several analysis tools for Plutus.</p>
<p>We are also finding common grounds to deepen our working relationship with Tweag. On another end, we continue to join IOG’s security workshops and cannot wait to join the first in-person conference next month in Barcelona.</p>
<p>Please follow the Hachi <a href="https://blog.hachi.one/">blog</a> for more information.</p>
<h2 id="economics">Economics</h2>
<p>The economics team’s primary responsibility is surveying all the relevant blockchains and DeFi protocols to understand the market and better design the economics and tokenomics of MELD products. We currently have several products built on our lending engine to design, simulate, and optimise. Given their research and academic-driven background, the economics team plays a massive role in formalising the products and simulating them with data. Concrete results will be included in the upcoming white paper releases.</p>
<p>The economics team has also been working on and writing several economic proposals to protect the MELD token’s price and create healthy markets. Another critical responsibility is treasury management to ensure the project utilises its capital well for the many years ahead.</p>
<p>We also seek to build a tight data infrastructure for quantitative and economics modelling. It is not trivial to build one on Cardano, but our advances on cardano-index seem very promising. Hachi’s low-level research on the automatic inference of (not so complex) datum types to simplify security properties may be applicable here; to accurately track DeFi data to every detail, even for projects that have not open-sourced their code.</p>
<h2 id="meldapp">MELDapp</h2>
<p><img src="/technical/assets/akamon-ui-teaser-2.png" alt="Akamon UI Teaser" /></p>
<p>Our major win lately was building a better UX research and design approach. While much more time is still required to formalise the process, we continue to aim for the best DeFi experience. Another win has to do with several improvements to our whole backend infrastructure. Much effort has been made to ensure we have the best infrastructure for development, staging, and production environments. Both works have been critical as we expand our development scopes and seek to launch several products towards the end of the year.</p>
<p>For now, the number one task is to complete the Akamon integration for the first testnet launch in May. The MELD Governance suite of variable staking, protocol fees sharing, and voting on protocol proposals are right after. As we release additional functionalities, we also plan to release more wallet support on Cardano, Polygon, and more networks as Akamon grows its reach.</p>
<h2 id="conclusion">Conclusion</h2>
<p>The past 45 days have been foundational to further stabilising the teams, products, tooling, and development processes. We are now looking forward to an aggressive roadmap of monthly launches and updates. We expect to launch on the 5th, post a technical update on the 15th, and post a white paper update and a teaser video on the last day of every month. Hang tight!</p>Technical Report 2022/03/022022-03-01T17:00:00+00:002022-03-01T17:00:00+00:00https://meld-labs.github.io/technical/reports/2022/03/01/technical-report<h1 id="technical-report-20220302">Technical Report 2022/03/02</h1>
<p><img src="/technical/assets/meld.jpeg" alt="MELD" /></p>
<p>Welcome to the first MELD technical report of 2022!
It has been an aggressively progressive two months for us sprinting for the launch, the launch itself, production issues, UX improvements, and working towards the upcoming products.</p>
<p>While we have stumbled on quite a few production issues, it has been a great learning experience developing on a new frontier. Furthermore, going through the troubles together has significantly united the whole R&D department. We have transitioned from segmented teams (economics, blockchain, MELDapp, and UI/UX) with minimal communication to a tight division with many professional and personal common goals and laughter!</p>
<p>Let us review what the team has achieved in the last two months and look forward to what this tight unit can produce next.</p>
<h2 id="cardano">Cardano</h2>
<h3 id="pab">PAB</h3>
<p>We needed several modifications but have launched and scaled PAB for our vesting and staking contracts on mainnet. We have then brainstormed on a better PAB architecture going forward that is way leaner and more efficient than the current one. We have proposed a high-level architecture to the Plutus team and planned to build the low-level building blocks ourselves.</p>
<p><img src="/technical/assets/proposed-pab-architecture.png" alt="Proposed PAB architecture" /></p>
<p>A few key takeaways are:</p>
<ul>
<li>The current PAB architecture is overly bloated and inefficient.</li>
<li>We need a better balancing solution going forward. See <a href="https://github.com/input-output-hk/plutus-apps/issues/249">input-output-hk/plutus-apps#249</a> for more details.</li>
<li><code class="language-plaintext highlighter-rouge">plutus-chain-index</code> does not scale on the mainnet. It requires too much resource, leaks memory, sometimes syncs slower than block-production rate, and a <code class="language-plaintext highlighter-rouge">utxosAt</code> on mainnet could take hours to resolve, if not hanging forever. dApps should build their indexing solutions on <code class="language-plaintext highlighter-rouge">plutus-chain-index-core</code> or something equivalent to scale. The key is fully controlling one’s DB schema to fund the fastest possible queries.</li>
<li>Building transactions should not be a stateful process across multiple requests.</li>
<li>Overall, the <code class="language-plaintext highlighter-rouge">Contract</code> monad and <code class="language-plaintext highlighter-rouge">EmulatorTrace</code> are too far from a real-life setup to have much production value. We should build transactions in a stateless way and test them on a private network instead.</li>
<li>Building transactions with PAB endpoints & constraints is inflexible and does not share code with on-chain state machines when they are still unusably oversized. We should have more flexible low-level tooling to build arbitrary transactions.</li>
<li>We need a better testing framework for dApps, that is relevant to a real-life production setup.</li>
<li>The ecosystem needs and deserves a <code class="language-plaintext highlighter-rouge">plutus-starter</code> with full PAB support from a local development setup to mainnet deployment.</li>
</ul>
<p>Hopefully, we will see a new PAB or something equivalent soon to aid the whole ecosystem in off-chain integration. We are in the game ourselves and hopefully will report on our progress soon.</p>
<h3 id="hydra">Hydra</h3>
<p>We continue to discuss potential contributions and building dApp demonstrations for Hydra with the Hydra team. The main goal is to identify and build practical use cases of Hydra, then a starter template with decent integration documentation for better developer experience and adoption.</p>
<p>We also have a P2P variant that might scale several (but not all) dApps in a non-custodial way that we want to prototype. The key is not to build the whole stack ourselves but to build the protocol on top of the Hydra team’s great core.</p>
<p>We also have a long overdue backlog to build isomorphic state channel demos on Nervos for better tooling hence quicker prototyping. Hopefully, we will soon allocate more resources to build two monsters on both chains and write dedicated technical reports about them.</p>
<h3 id="developer-experience">Developer Experience</h3>
<p>We continued to pitch about the importance of better developer experience to help Cardano developers progress faster and make it easier for projects to recruit and train. The main improvements would revolve around:</p>
<ul>
<li>Better documentation.</li>
<li>Better dependency management.</li>
<li>Better tooling.</li>
</ul>
<p>We have been discussing the problem with IOG and other players in the ecosystem, and it looks like improving the developer experience will be a gradual process. We have planned an internal knowledge base that could be adapted to a public one, dependency and tooling work both internally and for public contributions. Another critical effort is building a dApp starter template with everything included and optimized for local development and production deployment. The goal is to include Nami support, a new PAB architecture, Hydra integration with disciplined code, documentation, and tests.</p>
<p>We hope to push more public contributions and open-source more work in the upcoming months. Another interesting to do is to get more involved in the design and implementation of the CIPs, especially those critical to our dApp works like in CIP 30, 31, 32, and 33.</p>
<h2 id="hachi">Hachi</h2>
<p>Hachi is a security research effort on Cardano that MELD helps fund.</p>
<p>In the last two months, Hachi has been invited to give a presentation at an IOG seminar and a series of technical workshops on dApp certifications and auditing standards. The goal is to help push security research, standards and tooling on Cardano with the whole ecosystem.</p>
<p>On the other hand, after months of diverse research and experiments, Hachi has now focused solely on dApp-developer-friendly tooling for Plutus Core operations and analysis. Please follow their <a href="https://blog.hachi.one/">blog</a> for more information.</p>
<h2 id="adamatic">ADAmatic</h2>
<p><img src="/technical/assets/adamatic.png" alt="ADAmatic banner" /></p>
<p>We continued to sprint with Obsidian Systems towards a testnet launch this Q1. MELDapp integration has started, so it has been quite exciting on this end. We are putting more attention and resources (UX, economics, blockchain, product design, and MELDapp integration) into the project as it will be our next major release. Frequent announcements and articles will be posted to communicate progress towards launch, with a dedicated White Paper and technical reports here and there to make sure everyone is aligned.</p>
<p>For now, the short-term goal of ADAmatic is to bring more liquidity into Cardano, enable more utility for Cardano native tokens on either side of the bridge, and innovate dApp designs on the UTxO ledger. Longer-term goals include supporting more chains (for example, through RenVM) and enabling cross-chain contract interactions.</p>
<p>More public announcements will begin soon. Hang tight!</p>
<h2 id="economics">Economics</h2>
<p>The economics team has been in better shape with better management and a new engineer helping with software tasks. We now have a live token to take care of, with clearer product visions to design the economics models for.</p>
<h3 id="market-marking">Market Marking</h3>
<p>We need to create a market for the MELD tokens. The near future goal is to provide liquidity to the exchanges for people to trade on and encourage traffic to get the MELD token to more significant exchanges. We can stop the effort once the MELD markets are stable and carry on themselves.</p>
<p>We have conducted in-depth studies on market-making solutions available on the market, especially Hummingbot, a leading software in the crypto world. Few independent functionalities and strategies have been added to Hummingbot for future usage.</p>
<p>We then proposed several market-making algorithms that potentially work well in a high-frequency trading environment with a backtesting framework for the algorithms’ out-of-sample performance. On top of that, we have been working on a marketing making, more generally, a trading framework with early support for BiTrue and FMFW. Most works are still experimental, but we are confident of hitting production by April. Until now, another consultant has been operating on a microscopic scale on the initial exchanges.</p>
<p>Finally, we have built and maintained a real-time database for the MELD tokens’ transaction data for different analytical purposes.</p>
<h3 id="buyback">Buyback</h3>
<p>We have been monitoring the MELD token’s price and have two buyback strategies in certain conditions to relieve investors and restock MELD for future liquidity and reward programs. These buyback algorithms are built upon careful statistical analytics on the price-dropping rate and recovery rate of similar DeFi protocol tokens.</p>
<p>Hopefully, the proposals stay shelved and untouched forever, with the tokens growing organically with the whole ecosystem. Regardless of the circumstances, it is always nice to have a backup plan.</p>
<h3 id="quantitative-investment">Quantitative Investment</h3>
<p>We have built a database on trading prices and the volume of almost every token for investment research purposes. We have also conducted and implemented several quantitative trading algorithms, including trend-following, mean reversals, trend-segmentation, and backtested performance. The key is to utilize the project’s capital to enable constant expansion, and MELD is here to stay through all market conditions.</p>
<h3 id="economic-modelling">Economic Modelling</h3>
<p>We have reviewed many research papers and protocols in-depth, including stablecoin design models, lending protocols, blockchain protocols and cross-chain bridges. This critical effort boosts our understanding of the space to plan better economic models and products.</p>
<p>The current scope includes:</p>
<ul>
<li>Economics forecasting for ADAmatic.</li>
<li>Protocol fees for ADAmatic and MELD’s upcoming dApps.</li>
<li>ADAmatic and MELD tokenomics for governance.</li>
<li>Economic models for MELDed Fiat and Lending.</li>
</ul>
<p>On top of that, the team has proposed brand new ideas like partially collateralized stablecoin, limit-order-book-like lending models, and liquidity bridge.</p>
<h2 id="meld-smart-contracts">MELD Smart Contracts</h2>
<p>Pre-launch, the Blockchain team focused on dApp integration, scaling off-chain infrastructure for the vesting & staking smart contracts, and delivering production duties with the successful airdrop and contract launch. It took an extra week post-launch to scale PAB as it got prolonged as the mainnet data grew.</p>
<p>After that, we are polishing the codebases for better structure, documentation, and tooling. More importantly, we have many off-chain ideas to explore and implement, like better PAB, better indexing solutions and transactions builders, better scalability, a realistic and more robust testing framework, and more. The quest to refine the infrastructure and code bases live on as we perfect the foundation to deliver the more complex products.</p>
<p>Finally, we put tremendous effort into contract design on Cardano. We expect to design more pleasing contracts with the highly anticipated CIPs in 31, 32, and 33. For that, we have had regular, almost daily technical workshops to propose new ideas, debate, generalize building blocks, and formalize ideas into concrete design documents.</p>
<p>The current scope is massive:</p>
<ul>
<li>Highly generic and composable design patterns.</li>
<li>On-chain migration.</li>
<li>ADAmatic smart contracts.</li>
<li>Variable staking.</li>
<li>MELD governance with staked voting.</li>
<li>MELDed Fiat.</li>
<li>A sample dApp for a starter template.</li>
</ul>
<p>We will start to open-source different code bases as we refine them and add documentation. We have a lot to share and hope to contribute upstream more to the whole ecosystem.</p>
<h2 id="meldapp"><a href="https://app.meld.com/">MELDapp</a></h2>
<p><img src="/technical/assets/meldapp.png" alt="MELDapp" /></p>
<p>The MELDapp team was highly instrumental in the launch. We completed the first release of the MELDapp with Nami integration and glued everything together to launch several infrastructure environments for staging, production, Cardano testnet and mainnet.</p>
<p>It took extra time to scale and stabilize post-launch, but things have gone well with many critical lessons learned. The operational lesson for creating vesting positions with all the wallet miscommunication and mismatches was worth mentioning.</p>
<p>Much effort is also put into improving error messages, user notifications, responsive layouts, and UX, our top priority only behind security. We have also formed an in-house UX club to further research and improve going forward.</p>
<p>Similar to the Blockchain team, we are polishing the infrastructure and code bases for better structure, documentation, and performance to extend the products and deploy more complex ones on top of. Further works include supporting more wallets (CCVault, Yoroi, the builtin MELDwallet) and ADAmatic integration!</p>
<p>We have many more designs and prototypes for ADAmatic and future MELD products and cannot wait to release everything soon. Here is a quick ADAmatic mock for now!</p>
<p><img src="/technical/assets/adamatic-mock.png" alt="ADAmatic mock" /></p>
<h1 id="conclusion">Conclusion</h1>
<p>The whole MELD R&D department has significantly evolved in the last two months. We cannot wait to perfect our current setups and deliver many more products to the market. Hang tight. ADAmatic will soar next!</p>Technical Report 2022/03/022021 End of Year Report2021-12-31T16:59:59+00:002021-12-31T16:59:59+00:00https://meld-labs.github.io/technical/reports/2021/12/31/end-of-year-report<h1 id="2021-rewind">2021 Rewind</h1>
<p><img src="/technical/assets/meld.jpeg" alt="MELD" /></p>
<p>We have finally come to the end of 2021 – the first year in the MELD journey with over three quarters of insane activities and development. This report summarizes the technical progress of MELD in 2021 and what we can look forward to in 2022. More details will be posted in their dedicated posts next year.</p>
<p>Let us start with the more community-driven works before getting to the core of MELD.</p>
<h2 id="cardano">Cardano</h2>
<p>MELD’s mission is to bring secure, efficient, and low-barrier-to-entry financial services to the mass. Such a mission is technology-agnostic by definition, and we will do whatever is best towards that goal.</p>
<p>For now, MELD started as a Cardano project and is determined to stay so in the foreseeable future. Early platforms take time to mature so we have to practice patience more than expected. Nevertheless, as eager developers, we did enjoy the daily challenges. We also prefer to develop from principles and treat products as profound works. As such, being early in Cardano allows us to stay closer to the core progress of the ecosystem itself.</p>
<p>In 2021, we mainly contributed to Plutus when we could afford the time. We hope to be even more active, supportive and organized in 2022 with frequent discussions with the core Plutus team themselves. We have also studied Hydra to understand the keys to isomorphic state channels, to contribute to Hydra and design our own variants for MELD. Like Plutus, we have met the IOG scalability team and expect more technical workshops in the future. We want to be one of the first Hydra users, build it with the whole community, and propose own variants in Q1 2022.</p>
<p>We have also spent some effort trying to master Ouroboros but it has not gone far given our current deadlines. We expect to resume Ouroboros and more topics in 2022 to join more intriguing challenges in the consensus, ledger, and node works.</p>
<h3 id="dependency-updates">Dependency Updates</h3>
<p>The Cardano codebase has been moving very fast! We frequently test our projects with the latest updates to evaluate and help fix breaking changes when possible. A few samples:</p>
<ul>
<li><a href="https://github.com/input-output-hk/ouroboros-network/pull/3282">input-output-hk/ouroboros-network#3282</a>.</li>
<li><a href="https://github.com/input-output-hk/cardano-node/pull/2998">input-output-hk/cardano-node#2998</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus/pull/3754">input-output-hk/plutus#3754</a>.</li>
<li><a href="https://github.com/input-output-hk/cardano-base/pull/235">input-output-hk/cardano-base#235</a>.</li>
<li><a href="https://github.com/input-output-hk/ekg-forward/pull/1">input-output-hk/ekg-forward#1</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/pull/46">input-output-hk/plutus-apps#46</a>.</li>
</ul>
<p>A few breaking APIs require some reasoning, but following Git history and GHC compile errors are sufficient most of the times. The process is also not that involved to learn more about these different Cardano components. That said, it is still nice to test our software with newer dependencies and help contribute when possible. We expect to continue this work when opportunities arise in 2022.</p>
<h3 id="better-developer-experience">Better Developer Experience</h3>
<p>We have to confront the truth that developing on Cardano, or any young ecosystem for the matter, is brutal. Cardano possesses further challenges given its not-very-industry-friendly technical stack. It is sometimes challenging to get the right things up, even for experienced Haskell and Nix engineers. It gets way worse for our interns and newcomers to the ecosystem. The relatively high system requirements and lack of documentation do not help either. A few detailed pain points can be found in <a href="https://github.com/input-output-hk/plutus-apps/issues/180">input-output-hk/plutus-apps#180 Plutus on Hackage/Stackage</a>.</p>
<p>As an ambitious R&D-driven effort, we have to recruit and train many engineers to work in the Cardano ecosystem. A few brilliants have refused to join or given up so far. While we cannot tell the exact reasons, we believe it would be easier to convince them if the developer experience was better, i.e., to help them feel more productive with their time and talents. After all, there are still many good opportunities outside of MELD and Cardano for these bright minds.</p>
<p>As a result, we are determined to help improve the developer experience on Cardano. The main two lines of work are tooling and documentation, with better development environments a nice place to start.</p>
<p>For instance, we have been trying to make <code class="language-plaintext highlighter-rouge">plutus-apps</code> thinner for dApp developers to at least build faster:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/212">input-output-hk/plutus-apps#212 Remove mandatory playground and PureScript dependencies from PAB</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/pull/213">input-output-hk/plutus-apps#213 Refine executable dependencies</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/pull/214">input-output-hk/plutus-apps#214 Refine dependencies and remove unused packages</a>.</li>
</ul>
<p>Trying to make <code class="language-plaintext highlighter-rouge">plutus</code> projects easier to build outside of patched GHCs:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/4299">input-output-hk/plutus#4299 Support non-patched GHC outside of haskell.nix</a>.</li>
</ul>
<p>With a few efforts here and there to improve <code class="language-plaintext highlighter-rouge">stack</code> support, as Nix has a steep learning curve, resource-intensive, and sometimes have flaky behaviours outside of NixOS and Linux.</p>
<ul>
<li><a href="https://github.com/commercialhaskell/stack/pull/5659">commercialhaskell/stack#5659 Support sub-library dependencies</a> (for <code class="language-plaintext highlighter-rouge">cardano-api:gen</code>).</li>
<li><a href="https://github.com/HachiSecurity/plutus-resolver">HachiSecurity/plutus-resolver</a> (from friends at Hachi!).</li>
</ul>
<p>Some documentation efforts:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3707">input-output-hk/plutus#3707 More documentation work</a> (sadly outdated at the moment).</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/129">input-output-hk/plutus-apps#129 Improve Chain Index documentation</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/130">input-output-hk/plutus-apps#130 Add a swagger ui page for chain index endpoints</a>.</li>
</ul>
<p>We have also seen many positive movements both from the Plutus team like in:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/4280">input-output-hk/plutus#4280 Doc: add a first page on double-satisfaction</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus/pull/4293">input-output-hk/plutus#4293 Add a doc on optimization techniques for scripts</a>.</li>
</ul>
<p>And from the community like in <a href="https://github.com/Plutonomicon/plutonomicon">Plutonomicon/plutonomicon</a>. We are excited to join hands with these greats and build a more developer-friendly ecosystem together. Hopefully, this time next year, anyone can quickly spin up a development environment to iterate on dApp ideas with confidence, thanks to better tooling and documentation. Then with a stable and efficient environment for prolonged development comes even more greats to the ecosystem.</p>
<h3 id="pab--chain-index">PAB & Chain Index</h3>
<p>We have been using, customizing and contributing to PAB since March. Our wildest customizations were in the PAB 1.0 days with the Plutus Playground UI. We even had a customized Chain Index tracking application-specific data and serves them cleanly through custom GET endpoints. We still remember fondly how <a href="https://github.com/input-output-hk/plutus/pull/2801">input-output-hk/plutus#2801 PAB v2</a> nuked everything (for the better, of course!) and how we slowly transitioned to Emulator traces when new Plutus updates were desired.</p>
<p>From that point onward, we became a lot more careful with our customized tooling and tried to contribute upstream more. Here are a few examples:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3853">input-output-hk/plutus#3853 Improve ChainIndex config handling</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/4">input-output-hk/plutus-apps#4 Chain Index questions and improvement proposals</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/68">input-output-hk/plutus-apps#68 Chain Index app: query the tip of the node for first response before start</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/71">input-output-hk/plutus-apps#71 Chain Index: separate scripts and redeemers tables</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/72">input-output-hk/plutus-apps#72 Chain Index: users can configure to only store txs from a block no onward</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/77">input-output-hk/plutus-apps#77 PAB: More consistent slot configs</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus-apps/issues/222">input-output-hk/plutus-apps#222 More chain index configs</a>.</li>
</ul>
<p>Regardless of the contributions, we have spent more time on emulator traces this year for core contract works and would need more time to master PAB for off-chain integrations. We have been stacking exciting ideas to propose to the Plutus team. Our primary focuses are better setup, API, and documentation for PAB users and better runtime performance.</p>
<p>We are expected to serve millions of users in 2022 (Tingo users alone are in millions) and integrate with many banking services, so we naturally have high demands for performant off-chain integrations. Learning from the PAB v2 destruction in April, we would love to do most PAB work directly upstream. We are also ready to roll our own solutions with Elixir and Rust when high performance is required. The best part is that all these solutions can still be integrated.</p>
<h3 id="plutus-script-size">Plutus Script Size</h3>
<p>Cardano currently has a tight transaction size limit, and for good reasons. However, this limitation makes it hard for dApps to include many scripts in a single transaction for composability and clarity. We have faced many challenges representing complex application logic within the current limit and had to resort to hacky or semi-trustful designs at times. The aftereffect is that dApp development is very inefficient and error-prone. Sometimes we feel like spending most of the time reasoning about security properties, contract architectures on UTxO, ad-hoc script size optimizations instead of working on actual application logic. It is not the end of the world, but an apparent overhead when expanding dApp functionalities and inviting more builders to Cardano.</p>
<p>Therefore, we are determined to contribute anything upstream for smaller script sizes. The near-future goals are to represent more logic, handle more data in validator scripts, and fit sane code well to remove the need for hacky solutions. A longer-term goal is to support state machines for better abstractions, analysis and faster development. We have discussed a few on-chain solutions internally and will start proposing when we have more time in January. For now, we slightly prefer compiler optimizations so that no hard-forks nor node updates are required, and improvements can be made locally and flexibly in a single project’s scope. A few examples:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/issues/4158">input-output-hk/plutus#4158 Compiler: remove unused data constructors</a> (Thank you, Michael, for your patience on this big mess, I do hope to clean it in 2022!).</li>
<li><a href="https://github.com/input-output-hk/plutus/issues/4174">input-output-hk/plutus#4174 Compiler optimizations for smaller script outputs</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus/issues/4219">input-output-hk/plutus#4219 Add a compiler option to remove traces</a>.</li>
<li><a href="https://github.com/input-output-hk/plutus/issues/4304">input-output-hk/plutus#4304 Inline trivial lambda bindings, to beta-reduce later on for smaller scripts</a>.</li>
</ul>
<p>We still need more time to get comfortable with Plutus and its compilation pipeline. We are looking forward to a new year full of studies, contributions, and sharings within the tight Plutus ecosystem.</p>
<h3 id="hydra">Hydra</h3>
<p>We have studied most Hydra materials and joined many Hydra conversations this year:</p>
<ul>
<li><a href="https://github.com/input-output-hk/hydra-poc/pull/107">input-output-hk/hydra-poc#107 [Experiment] Plutus hacks to improve mainchain interaction performance #107</a>.</li>
<li><a href="https://github.com/input-output-hk/hydra-poc/discussions/113">input-output-hk/hydra-poc#113 How can Hydra scale dApps?</a>.</li>
<li><a href="https://github.com/input-output-hk/hydra-poc/discussions/116">input-output-hk/hydra-poc#116 How to run NFT auction in Hydra Head?</a>.</li>
</ul>
<p>There is still a long road until Hydra can scale dApps, and we want to help push it there. We will continue the conversations internally, with the Hydra team and the community, and cannot wait to contribute PRs and propose our variants. We are also developing those variants on Nervos. Exciting time ahead!</p>
<h3 id="more-core-works">More Core Works</h3>
<p>In 2022, we would like to venture into more core works like with the ledger, consensus, and node to better understand Cardano and design the best solutions accordingly.</p>
<p>We have, for example, had a Plutus suggestion implemented at the ledger level for Plutus v2:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/issues/3844">input-output-hk/plutus#3844 Redeemers in Script Context</a>.</li>
</ul>
<p>Important: Reading redeemers in script context to make validation rules more concise and scripts smaller was Duy’s idea. kk-hainq in the above issue was just the delivery boy.</p>
<p>It has also been several months since Dat and Quang proposed two general solutions to the concurrency challenge <a href="https://meld-labs.github.io/technical/reports/2021/09/19/technical-report.html">here</a>. Many difficulties on layer-1 prevent these general solutions from functioning as intended, and ad-hoc optimizations are still preferred on Cardano at the moment. Since then, we have learned a lot more to polish and improve the proposals next year.</p>
<h2 id="haskell">Haskell</h2>
<p>Haskell plays a vital role in the Cardano ecosystem as the primary programming language in the technical stack. Cardano seems to attract several engineers, us included, for its use of Haskell in production. That said, it is more or less apparent that there are still many pain points in using Haskell for large-scale projects. The main problems are the relatively small community, limited tooling, the difficulty in recruitment and training, compile-time, runtime performance, and resource requirements. These are not impossible to handle, but it might worth trying to improve the situation at source if we choose to run the marathon with Haskell.</p>
<p>With that in mind, we have attempted to work on our first GHC work as suggested by the Haskell Foundation:</p>
<ul>
<li><a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6353">ghc/ghc#6353 Convert diagnostics in <code class="language-plaintext highlighter-rouge">GHC.Tc.Validity</code> to proper <code class="language-plaintext highlighter-rouge">TcRnMessage</code> (Part 1)</a>.</li>
<li><a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6511">ghc/ghc#6511 Convert diagnostics in <code class="language-plaintext highlighter-rouge">GHC.Tc.Validity</code> to proper <code class="language-plaintext highlighter-rouge">TcRnMessage</code> (Part 2)</a>.</li>
</ul>
<p>We hope to help make GHC error outputs more structured for tools like HLS to utilize directly instead of parsing raw text outputs. It went fine for a while until we simply failed to allocate any time for it. Hopefully, with the upcoming waves of engineers in 2022, we can be a bit more active on this front.</p>
<p>As our difficulty list suggested, our primary focus at the moment is to make Haskell development more practical, especially to newcomers that we hire and train. Apart from tooling like the above GHC work and sub-library dependency support in <code class="language-plaintext highlighter-rouge">stack</code>, we are also interested in making compile-time faster, reducing resource requirements, and improving runtime performance through better garbage collection or something. Then maybe in five years, we can start working on the beautiful type system and more theory-heavy works like that.</p>
<p>Nix is also an ecosystem we are interested in contributing being central to the Cardano ecosystem and heavily used by many of our technical partners. That said, similar to Haskell; we might love it dearly on paper but have also suffered several pain points using it in practice. When resources are still limited, we would probably avoid Nix for a while more.</p>
<p>It is important to note that Haskell is not our go-to language. We choose what makes sense for each specific purpose. Rust and Elixir will also be core in 2022, with hard opposites like Python and Javascript where appropriate.</p>
<h2 id="hachi">Hachi</h2>
<p>MELD has helped fund Hachi entirely up till now. We need dedicated security research to achieve our dApp ambitions for the MELD protocol and the greater Cardano ecosystem.</p>
<p>Here is a quick summary of what Hachi did in 2021:</p>
<ul>
<li>General:
<ul>
<li>internal documentation, experiments, and public blogs on Plutus and blockchain security.</li>
<li>a few Plutus libraries and tooling here and there.</li>
</ul>
</li>
<li>A Plutus chain index customized to sync security-relevant data from the chain.</li>
<li>Different grammar formats and transpilers for Plutus Core that target Scheme, Racket, LLVM IR, WebAssembly, C, Javascript, Python, and more.</li>
<li>A Plutus Core playground where one can edit and evaluate Plutus Core in the browser.</li>
<li>Plutus Core analysis tools, like attempting to infer type for core terms. It is undecidable in theory, but there are practical cases where type inference at the core level is very useful.</li>
<li>Racket-based tooling:
<ul>
<li>Concolic execution on top of Rosette.</li>
<li>Instrumentation for Plutus Core.</li>
<li>AFL++based fuzzer.</li>
<li>AFL-based concolic execution fuzzer.</li>
<li>Symbolic execution for transpiled Plutus Core.</li>
<li>Plutus’s built-in functions in Bigloo.</li>
</ul>
</li>
</ul>
<p>Big thanks to Quang, Quynh, Nicholas, and Michael for that list!</p>
<p>Hachi has also had a warm demo with IOG and got invited to further seminars and meetings as a result. We are looking forward to connecting Hachi to more auditors like Runtime Verification and CertiK, on top of the current partner in Tweag. It is fascinating to see researchers getting together for profound works on a new ecosystem. Both MELD and Hachi would love to be a part of that.</p>
<p>As an ambitious venture with a different focus, Hachi is expected to separate and grow on its own from August 2022. We can think of it as the Plutus repo split with Hachi being <code class="language-plaintext highlighter-rouge">plutus</code> and MELD being <code class="language-plaintext highlighter-rouge">plutus-apps</code>. Different goals and structures but benefit from each other to thrive!</p>
<p>Please visit <a href="https://blog.hachi.one/">Hachi’s blog</a> for more information. 2022 will be an exciting Hachi year with the first wave of products and more focused directions.</p>
<h2 id="adamatic">ADAmatic</h2>
<p>We want to thank Obsidian Systems, especially Rune and Tom, for their consistent ADAmatic bridge work!</p>
<p>Since September, the earliest version of mADA has been deployed and tested on Mumbai at <a href="https://mumbai.polygonscan.com/address/0xc70a3cd8ff5775d27e79f106f30fe94ff8186768">0xc70a3cd8ff5775d27e79f106f30fe94ff8186768</a>. The latest iterations moved all tests to local private testnets on both sides for more reproducibility and consistency. More features, optimizations, and auditing are still required, but we expect the first public testnet launch in January.</p>
<p>It is important to note that the first testnet version of the bridge will be centralized and custodial without smart contracts. It is a deliberate choice to first focus on the core of the ADAmatic node and how it interacts with the Cardano and Polygon nodes. We expect another public testnet launch with smart contracts and multi-signatures, with more decentralization and dApp integration proposals before the mainnet launch.</p>
<p>We are also completing the first public White Paper of the bridge from internal specification with more dedicated articles in general. Hang tight and prepare your Cardano and Polygon wallets!</p>
<h2 id="meld">MELD</h2>
<p>In alphabetical order, we would like to thank An, Dai, Dat, Dong, Duc, Duy, Frane, Huong, Ivan, Ivo, Karlo, Mario, Marin, Matej, Matija, Quang, Robert, Tam, Thanh, Thuy, Trung, and Tuan for their intricate and inspirational work in 2021. We cannot wait to add Binh, Hoang, Hrvoje, Sasha, Thanh, and many more next year.</p>
<p>Let us summarize some of the core works done this year before going into more details in the following dedicated posts.</p>
<h3 id="ispo">ISPO</h3>
<p>We have executed the world’s first large-scale ISPO at the peak of over a billion dollars worth of ADA in delegation. It was a huge commercial success without requiring much work on the technical side, showing just how good ADA staking is out of the box. That said, we still made a few technical mistakes when dealing with the pool tickers, KES keys, impersonations, ISPO dashboards, and more. While we only keep one MELD stake pool after the ISPO, the gained experience is still precious going forward as we collaborate with more SPOs to continue innovating on ADA staking. Dashboard difficulties also raised awareness around the importance of efficient and stable chain synchronizers and any off-chain solutions for the matter.</p>
<p>At the moment, we already have all the ISPO data on-chain to prepare the airdrop on January 31st 2022. We will soon complete an audit and open-source the codebase and all ISPO data.</p>
<p>For more information, you can read the intro to the ISPO <a href="https://medium.com/meld-labs/meld-initial-stakepool-offering-1ce37f203e06">here</a>, and the outro <a href="https://medium.com/meld-labs/meld-ispo-is-over-74e53a05229">here</a>.</p>
<h3 id="meld-nft">MELD NFT</h3>
<p>MELD is not an NFT project. That said, due to the high demand from the community and relatively mature tooling for NFT on Cardano, we started an NFT program called bank managers for the ISPO participants.</p>
<p>At a high level, anyone who has participated in the ISPO can claim an NFT and evolve it by solving MELD challenges. People can transfer and trade the NFTs like any other native assets. MELD holders can stake MELD with the NFT for better yield at launch. The higher the level of the NFT, the higher the yield. More high-level information can be found <a href="https://www.meld.com/nft">here</a>.</p>
<p>At a lower level, we focus on the principles like a script-based minting policy with an on-chain guarantee for NFT uniqueness. We also require the ISPO participants to pay to script-based vending machines instead of the project’s wallet. A more centralized solution might be easier to implement, batch, and execute in general. Nevertheless, we want to push for decentralization on the most mature front of Cardano dApps. We will have better batching when we have better script sizes. It would also be interesting to monitor Cardano’s performance during the high time of minting requests. More details and the codebase will be published in the upcoming weeks leading to launch.</p>
<p>We also have a special NFT for the ISPO diamond hands, which are more or less badges with no further utility. Or is there? We will announce more soon enough!</p>
<h3 id="smart-contracts">Smart Contracts</h3>
<p>We have designed and implemented several contracts in 2021, including vesting, staking, mFiat, lending, liquidation, governance, and experiments for ADAmatic, concurrent and deterministic batching, and more. Few have passed our quality requirements which resulted in the initial delays. As we grow with the UTxO ledger model, we have also developed brand new architectures to replace early models inspired by account-based ledgers like from Aave or Liquity. Several layer-one limits block the elegant and decentralized designs we demand in our contracts. Large-scale migrations are also not yet well-studied and supported on Cardano. Therefore, we have only signed off vesting and locked staking in 2021. We have been patiently experimented with and innovated more core contracts alongside Cardano’s and our growth.</p>
<p>For instance, we question the account-based state-driven DeFi that we know today. The intuition is that an asset is only liquid in the specific service it is deposited to, making the whole model capital-inefficient by default. Instead, we would like to redefine DeFi on highly parallel, multi-layered decentralized economies on the UTXO ledger. The nuance is that an asset can be lent or traded simultaneously. Then the total amount of borrowable and tradable assets can reach the total amount of assets in the economy.</p>
<p>As a result, we are not rushing the core products. While a fiat lending license is already in reach, we are still several months away from being able to lend fiat legally. Launching principle works after another hard fork or two would also benefit significantly from more layer-one improvements. The current focus is then on a successful genesis and first launch that incentivizes early MELD holders. Then we stay tight to get the most out of Cardano, Plutus, and Hydra to finalize the best products one can offer next year.</p>
<p>The current key components are:</p>
<ul>
<li>Decentralized protocol fees, to be integrated with ADAmatic and more.</li>
<li>Variable staking to withdraw rewards from protocol fees.</li>
<li>Liquidation specialized for UTxO.</li>
<li>Stablecoins specialized for UTxO.</li>
<li>Lending & borrowing specialized for UTxO.</li>
<li>Governance specialized for UTxO.</li>
<li>Integration with scaling solutions like Hydra, a MELD sidechain, and more.</li>
</ul>
<p>For the vesting and locked staking contract that we are launching on January 31st, here is an audit report from Tweag. In general, the contracts are straightforward, with no vulnerabilities found thus far.</p>
<embed src="https://meld-labs.github.io/technical/assets/tweag-audit-202112.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<p>As a final note, we are unhappy with ourselves for the massive time spent on re-designs, reasoning about security properties and contract architectures on UTxO, ad-hoc optimizations to reduce script sizes, and ad-hoc scalability solutions in 2021. Our primary goal in 2022 is to better formalize solutions and plans, and work with the whole community on tooling so that everyone can spend more time on actual application logic. The engineering team has been growing well towards the end of 2021 and are optimistic about further organized improvements.</p>
<p>We also plan to publish much more writing on contract architectures specialized for the UTxO ledger and the concrete designs of MELD contracts in 2022.</p>
<h3 id="economics">Economics</h3>
<p>Given our determination in helping make tooling and documentation better on the engineering side, we hope many people, regardless of background, can write dApps well in the future. On the other hand, economics modelling is relatively harder to generalize and has lower demands for tooling. In truth, all dApps need some engineering tooling, while not all are financial products nor need complex economics. Therefore, building an outstanding economics team is critical to MELD and will soon be a competitive edge over other projects in the same area.</p>
<p>Our economics works are principled, research-driven, and math-heavy, so we only summarise what has been done in 2021 here. We will publish much more dedicated writing in 2022.</p>
<p>For 2021, the team have:</p>
<ul>
<li>Had many brainstorming sessions on varied topics, from economics designs for MELD core products, ADAmatic, other popular DeFi applications like DEX, to game theory for layer-two solutions like Hydra and ADAmatic.</li>
<li>Run training sessions for engineers on economics, finance, and the mathematics involved.</li>
<li>Written a decent amount of internal documentation. Although much more is required to match our ambitions.</li>
<li>Modelled vesting, staking costs and rewards with detailed analysis on investor and staker behaviours, expectations and token pricing.</li>
<li>Forecasted MELD economics on lending (without vesting). These include lending and borrowing rates, MELD token price, revenue growth, total locked value, costs of incentive scheme, and more.</li>
<li>Discussed a better inflationary economy for MELD v2 in 3-5 years.</li>
<li>Modelled ADAmatic economics with basic assumptions from similar projects. A lot more data is required to iterate on improvements.</li>
<li>Worked on market-making frameworks and buyback plans to protect the MELD token price and its holders.</li>
<li>Worked on different investment models to further utilize the project’s capital.</li>
<li>Built simple data pipelines for centralized exchanges.</li>
<li>Proposed many new lending, stablecoin, exchange, and economics designs in general.</li>
</ul>
<p>Our number one difficulty is building the data team that, in turn, builds efficient data pipelines and warehouses for the Quant researchers to backtest their models. While most models have already been simulated in one way or another, nothing is close to constant live data from the platforms that we are on. On this note, as we see more dApps launched on the Cardano mainnet, we are starting to have real-life DeFi data, which is a lot better than where we were six months ago. We cannot wait to serve the researchers the data they need and to see lively data pipelines from a Cardano node straight to the economics models and dashboards.</p>
<p>Another important task in 2022 is for the engineers to further study economics, finance, and mathematics and for the researchers to study blockchain and Cardano to better communicate and co-design products. Our ambitious projects do require harmonized depths from both worlds.</p>
<h3 id="meldapp">MELDapp</h3>
<p>Our number one mistake in 2021 was to have a Zagreb team and a Vietnam team working separately under different management and cultures. As weak leaders, we unconsciously considered the Vietnam team more core as they had more workload in the early days and worked on the more internal components of the products. For that reason, the blockchain and economics teams there have received a lot more care and support to thrive. On the other hand, the MELDapp team in Zagreb did not have the best working environment, got vague requirements, late feedback, and more. Having to handle imprecise yet unrealistically high demands with unstable tooling on Cardano, the team had to work under tremendous stress, and the MELDapp got delayed again and again. I am utterly ashamed and sincerely apologize to the MELDapp team and all of our users for it.</p>
<p>As a solution, we have been erasing the boundaries between the teams to unify management and cultures. We also have core researchers and engineers in Canada, Europe, and Singapore at the end of the day.</p>
<p>Furthermore, UX is our number two criteria right behind security. The MELDapp is expected to be installed in millions of devices in 2022 through partnerships like with Tingo. With the current toolset on Cardano, scalability solutions for off-chain components serving that traffic are not trivial. Our soon integration with banks and other fiat services would be brutal as well. There is no reason why the MELDapp team is not as core as the blockchain and economics teams, and absolutely no reason why we should not brainstorm to kill challenges together.</p>
<p>For now, we are hurrying to finalize the first version of the MELDapp to serve launch. Nami and Metamask integrations for Cardano, Polygon, and Ethereum wallets work. We also have a built-in Cardano wallet as another option. Integration with the ADAmatic bridge, vesting and staking contracts are being hurried on. There are still unfinalized designs due to overly detailed requirements and late feedback. However, given the current timeline, we also consider going with what we have first, to iterate on designs with user feedback afterwards. At least most UI components have been built now.</p>
<p>Everything is long overdue, but we do expect much more progress soon given the management and working cultures change. Again, sincere apologies to the team and all of our users who have been looking forward to the MELDapp. The intention of a UX-first application has not changed since day one, and we do owe everyone such a product for the many years to come.</p>
<h1 id="conclusion">Conclusion</h1>
<p>2021 has been a foundational year in MELD history. We have made several mistakes and learned many priceless lessons. From that, we are determined to make significant improvements on all fronts in 2022.</p>
<p>As an R&D-driven effort, we are incredibly grateful to our researchers and engineers for trusting the best years of their careers with us. In return, we must build a better working environment for them to innovate in 2022, and with that comes the great products that all MELD users deserve.</p>
<p>Last but not least, we would like to thank the researchers and engineers from these organizations:</p>
<ul>
<li>IOG: for laying the foundation for us to build on and for the patience reviewing our issues and PRs (especially the Plutus team).</li>
<li>Tweag: to the Tweag engineers at Hachi, the auditing team, and the Plutus team for doing much cool stuff with us.</li>
<li>Obsidian Systems: for our (you do most of the work thus far, but well…) work together on the ADAmatic bridge.</li>
<li>MLabs: for your massive contributions to the Plutus ecosystem. We are three letters and one space more but always jealous of your resourceful team. May our road cross some time next year.</li>
<li>Well-Typed: for your huge contributions to the whole ecosystem. May our road cross next year.</li>
<li>SundaeSwap: for your early pushes and displays through the difficulties.</li>
<li>Maladex: for your exciting ideas. Hopefully, we can explore more together next year.</li>
<li>Nervos: for your fantastic RISC-V support, layer-2 driven works, and tooling with Rust. Our resources have been limited this year, but we hope to build tons with you in 2022.</li>
</ul>
<p>That is it. Happy new year, everyone! Let us build many great products for the users in 2022!</p>2021 RewindTechnical Report 2021/09/192021-09-19T16:59:59+00:002021-09-19T16:59:59+00:00https://meld-labs.github.io/technical/reports/2021/09/19/technical-report<p><img src="/technical/assets/meld.jpeg" alt="MELD" /></p>
<p>We build MELD on top of the Cardano blockchain, so improving the platform is one of our priorities. This technical report gives insights into our contribution to the Cardano ecosystem and the progress of our internal projects so far in September.</p>
<h2 id="cardano">Cardano</h2>
<h3 id="plutus">Plutus</h3>
<h4 id="documentation">Documentation</h4>
<p>We have not been able to continue our public Plutus documentation work this month due to increased demand for internal writing. Fortunately, many of these internal works can be ported to our public Plutus documentation in the future.</p>
<p>Current progress:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3707">input-output-hk/plutus#3707</a></li>
</ul>
<p>A good news is that the first entry to Plutus V2 interface is here:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3952">input-output-hk/plutus#3952</a></li>
</ul>
<p>This PR includes essential improvements to <code class="language-plaintext highlighter-rouge">TxInfo</code> that we would love to document. For example, having redeemers in <code class="language-plaintext highlighter-rouge">ScriptContext</code> would lead to cleaner validator scripts to reason about. Fewer extra checks on datums would yield smaller-sized and faster scripts as well.</p>
<p>We are also looking forward to publishing our internal dApp standards with examples, from iterative protocol specifications & contract designs to coding standards.</p>
<h4 id="improve-chain-index-config-handling">Improve Chain Index Config Handling</h4>
<p>We continue to work with the Chain Index component for both security research and dApp development. This endeavor includes customizing the component to efficiently store and query any data we want, getting raw data from on-chain hashes, building specialized GET endpoints for MELD-specific applications, and more.</p>
<p><code class="language-plaintext highlighter-rouge">cardano-db-sync</code> is another great candidate for this use case. We prefer Chain Index for now because it is leaner to customize.</p>
<p>During our work, we opened a quick PR that improves config handling for <code class="language-plaintext highlighter-rouge">plutus-chain-index</code>:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3853">input-output-hk/plutus#3853</a></li>
</ul>
<p>This PR further distinguishes chain index & logging configs and supports printing default configs to file. Previously there was an unhandled <code class="language-plaintext highlighter-rouge">DumpDefaultConfig</code> CLI command, with a few misdescriptions between the two config types.</p>
<h4 id="fix-pretty-printing-fakenamedebruijn">Fix Pretty-Printing <code class="language-plaintext highlighter-rouge">fakeNameDeBruijn</code></h4>
<p>This fix is for a minor inconvenience we found with Hachi’s work.</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3865">input-output-hk/plutus#3865</a></li>
</ul>
<p>According to the Plutus Core specifications, names can only start with letters.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Name n ::= [a-zA-Z][a-zA-Z0-9_’]*
</code></pre></div></div>
<p>But previously <code class="language-plaintext highlighter-rouge">fakeNameDeBruijn</code> gave an empty <code class="language-plaintext highlighter-rouge">ndbnString</code>, which led to “invalid” pretty-printed programs in this scenario:</p>
<ul>
<li>Call <code class="language-plaintext highlighter-rouge">mkTermToEvaluate</code> on a <code class="language-plaintext highlighter-rouge">Script</code>.</li>
<li>The program is named with <code class="language-plaintext highlighter-rouge">fakeNameDeBruijn</code>.</li>
<li>The <code class="language-plaintext highlighter-rouge">NamedDeBruijn</code>s are translated to <code class="language-plaintext highlighter-rouge">Name</code> through <code class="language-plaintext highlighter-rouge">unDeBruijnProgram</code>.</li>
<li><code class="language-plaintext highlighter-rouge">prettyPlcClassicDebug</code>ing the program/term leads to names like <code class="language-plaintext highlighter-rouge">_0</code>, <code class="language-plaintext highlighter-rouge">_1</code> because of the <code class="language-plaintext highlighter-rouge">PrettyBy</code> instance of <code class="language-plaintext highlighter-rouge">Name</code>:
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>instance HasPrettyConfigName config => PrettyBy config Name where
prettyBy config (Name txt (Unique uniq))
| showsUnique = pretty txt <> "_" <> pretty uniq
...
</code></pre></div> </div>
</li>
</ul>
<p>This bug led to the <code class="language-plaintext highlighter-rouge">uplc</code> CLI itself failing to parse the program:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ cat alwaystrue.uplc | uplc print
uplc: Lexical error: lexical error at line 3, column 12
</code></pre></div></div>
<p>Our PR fixed it:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cat alwaystrue.uplc | uplc print
(program
1.0.0
[
[
(lam i_0_0 (lam i_1_1 (lam i_2_2 (lam i_3_3 (lam i_4_4 i_0_0)))))
(delay (lam i_5_5 i_5_5))
]
(lam i_6_6 i_6_6)
]
)
</code></pre></div></div>
<p>This fix is helpful for security researchers who do not use Haskell in their everyday work but can swiftly write parsers and transpilers for a well-scoped language like Plutus Core. These transpiling efforts are critical in utilizing existing security toolboxes for Plutus programs.</p>
<h4 id="check-full-outputs-in-plutuscontracttest">Check Full Outputs in <code class="language-plaintext highlighter-rouge">Plutus.Contract.Test</code></h4>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3947">input-output-hk/plutus#3947</a></li>
</ul>
<p>During testing, we often want to check the outputs at a single address. We already have <code class="language-plaintext highlighter-rouge">dataAtAddress</code> in <code class="language-plaintext highlighter-rouge">Plutus.Contract.Test</code>, but it only checks the datums:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>dataAtAddress :: forall d . FromData d => Address -> ([d] -> Bool) -> TracePredicate
</code></pre></div></div>
<p>We want to add another utility function that zips datums with <code class="language-plaintext highlighter-rouge">Value</code>s at each output:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>forall d. FromData d => Address -> ([(d, Value)] -> Bool) -> TracePredicate
</code></pre></div></div>
<p>Since this is only for testing, we suspect this can even replace <code class="language-plaintext highlighter-rouge">dataAtAddress</code> as a generalization covering more cases. Breaking people’s CI/CD is a bit rich, but a fix should be trivial enough.</p>
<h3 id="cardano-base">Cardano Base</h3>
<p>During our periodic dependency bumping, we found a failed orphan <code class="language-plaintext highlighter-rouge">Serialise</code> instance on <code class="language-plaintext highlighter-rouge">Hash</code> in <code class="language-plaintext highlighter-rouge">ouroboros-network</code> that gets propagated to places like <code class="language-plaintext highlighter-rouge">Ouroboros.Consensus.Mock.Ledger.UTxO</code>.</p>
<p>Since the new <code class="language-plaintext highlighter-rouge">PackedBytes</code> solution does not export the core module intentionally, we helped add a <code class="language-plaintext highlighter-rouge">Serialise</code> instance right there:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>instance Serialise (PackedBytes n) where
encode = encodeBytes . unpackPinnedBytes
decode = packPinnedBytesN <$> decodeBytes
</code></pre></div></div>
<ul>
<li><a href="https://github.com/input-output-hk/cardano-base/pull/235">input-output-hk/cardano-base#235</a></li>
</ul>
<p>We planned to add tests and try <code class="language-plaintext highlighter-rouge">packPinnedBytes</code> in place of <code class="language-plaintext highlighter-rouge">packPinnedBytesN</code> to decode tighter. The PR was merged before we could get back to it, so maybe next time.</p>
<p>We have also been looking at the use of FFI in this component. This effort aligns with our dedicated security research on Cardano and the Bounty Program from the Cardano Foundation.</p>
<h3 id="the-concurrency-challenge">The Concurrency Challenge</h3>
<p>We have always been aware of the concurrency challenge on the UTXO ledger where multiple agents compete to spend the same UTXO in the same block. We attempted to design our concurrent state machine months ago but stopped because it was not worth it. Layer-1 latency is always expected for a young ecosystem with small block size. We should either invest in a Layer-2 solution or focus on other areas like security and economics models first.</p>
<p>That said, the recent conversations on concurrency once again triggered our curiosity. We started small with some internal discussions that quickly led to more formalization efforts. We had to publish the first paper draft in just 2-3 days to help address heated questions without merits against Cardano’s concurrency capability. Since then, much more progress has been made: from more ideas, formalizing and verifying models with mathematicians, to building proofs-of-concept in different environments.</p>
<p>We are still against publishing immature research but hope the following drafts are helpful to other projects building on Cardano, especially when other proposed solutions lead people to trust non-consensus and non-deterministic off-chain bots. For example, a single-swap-batch races fastest in such a setting but is still rewarded for rendering a DEX one swap per block. No on-chain consensus is also a straightforward recipe for front-running and MEV. Hachi is ready to stress-test any protocol that trusts these independently racing bots. We are also unsure if it is considered a DoS attack when the protocol itself does not check or punish these malicious minimal batches. The bots are, in fact, still rewarded for submitting such batches. At the same time, it is still the users who pay for the steps.</p>
<h4 id="auto-scaling-concurrent--deterministic-batching-on-the-utxo-ledger">Auto-Scaling Concurrent & Deterministic Batching on the UTXO Ledger</h4>
<embed src="https://meld-labs.github.io/technical/assets/Auto_Scaling_Concurrent_Deterministic_Batching_on_UTXO_5.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<p>This architecture is designed explicitly for frequently updated on-chain states. It utilizes a deterministic validation rule that removes any influence from off-chain agents. The most significant trade-off is the congestion on the reserving phase, where users have to compete for a reserve. At least congestion comes from users that have to pay for each reserve. A continuous DoS is very expensive to maintain, and it is easy to guarantee a net profit to the whole dApp after every step. Applying minimal limits on each step in the reserving phase is also easier than on batches, a distinct advantage of local over global states.</p>
<p>After building a Proof-of-Concept on Cardano, we believe there are still limits on Layer-1 that prevent this solution from scaling. Deploying this architecture on a dedicated sidechain should solve those timing and congestion problems.</p>
<h4 id="long-term-quotaless-deterministic-batching-on-the-utxo-ledger">Long-Term Quotaless Deterministic Batching on the UTXO Ledger</h4>
<embed src="https://meld-labs.github.io/technical/assets/Long_Term_Quotaless_Deterministic_Batching_UTXO.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<p>These architectures accept some extra latency to remove the congestion on the reserving phase. It suites longer-term states like governance voting where the final state can wait, but people want no congestion when voting.</p>
<p>Again, deploying these architectures on a dedicated sidechain solves most timing and latency issues.</p>
<h4 id="one-shot-markets-redefine-liquidity-on-the-utxo-ledger">One-Shot Markets: Redefine Liquidity on the UTXO Ledger</h4>
<embed src="https://meld-labs.github.io/technical/assets/OneShotMarketsIntro.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<p>(The rest of the paper is confidential at the moment)</p>
<p>Apart from general solutions that work for most states like the above, we believe dApp developers should rethink contract design per application. Basically to design dApp models of, for, and by the UTXO ledger; instead of just fitting account-based state-centric keys to the UTXO locks.</p>
<p>For example, instead of replicating stateful economics models from the account-based world, MELD has designed a new UTXO-driven economic model called One-Shot Markets. The key is to create new markets, loans, and other economic components after consuming one market UTXO instead of maintaining on-chain shared states. This way, different markets can be processed in parallel, while multiple can be consumed together for more liquidity per transaction. This generalized market also allows a single UTXO to act as lending, liquidity, stake, or insurance pool, to be interacted differently to create different output markets per redeemer.</p>
<p>The removal of an on-chain global state also forces dApps to move more components off-chain. This simplification of on-chain validators usually leads to fewer edge cases, better security, cheaper and faster on-chain transactions due to less resource usage. It also encourages off-chain innovations. For example, when price discovery is made off-chain, a typical liquidity provider can follow a specific oracle, while more involved providers can do their own quantitative analysis and pricing strategies.</p>
<p>In summary, MELD is designing new economics models of, for, and by the UTXO ledger. Simultaneously, we are working on both Layer-1 and Layer-2 scaling solutions. We expect to build our own dedicated sidechain as MELD reaches a massive scale. Dedicated mathematicians are formalizing and verifying all these innovative works. We expect to publish a lot more results towards the end of the year.</p>
<h2 id="haskell">Haskell</h2>
<h3 id="ghc">GHC</h3>
<h4 id="errors-as-structured-values">Errors as (structured) values</h4>
<ul>
<li><a href="https://github.com/ghc-proposals/ghc-proposals/pull/306">GHC Proposal</a></li>
<li><a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values">Gitlab Wiki</a></li>
</ul>
<p>This body of work is instrumental. We want to join hands because there are newcomer-friendly tasks for us to get familiar with GHC work. We can then help integrate this new diagnostic infrastructure into <a href="https://github.com/haskell/haskell-language-server/issues/2014">HLS</a> and perhaps more toolings for Hachi.</p>
<p>Our first GHC MR that <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/20118">converts diagnostics in <code class="language-plaintext highlighter-rouge">GHC.Tc.Validity</code> to proper <code class="language-plaintext highlighter-rouge">TcRnMessage</code></a> has been merged:</p>
<ul>
<li><a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6353">ghc#6353</a></li>
</ul>
<p>We have been working on part two here:</p>
<ul>
<li><a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6511">ghc#6511</a></li>
</ul>
<p>Summary:</p>
<ul>
<li>Move <code class="language-plaintext highlighter-rouge">InstanceWhat</code> to <code class="language-plaintext highlighter-rouge">GHC.Tc.Types.Origin</code>.</li>
<li>Add <code class="language-plaintext highlighter-rouge">TcRnSimplifiableConstraint</code>.</li>
</ul>
<p>We have slowed down significantly due to the overloaded MELD and Cardano-specific works. That said, we are looking forward to introducing more college students to this project, to hopefully speed everything up to all the way to HLS integration.</p>
<h3 id="hlint">HLint</h3>
<p>We had another PR merged and continued to complete a long-overdue one:</p>
<ul>
<li><a href="https://github.com/ndmitchell/hlint/pull/1279">(Merged) Suggest NumericUnderscores</a>.</li>
<li><a href="https://github.com/MELD-labs/hlint/pull/1">Remove “junk” lines in long suggestions</a>.</li>
</ul>
<p>After a while, we concluded that a pure Plutus linter is not that useful at the moment. We are now directing Haskell training to GHC, HLS, and Cabal instead. Moreover, we have been exploring more powerful approaches like with <code class="language-plaintext highlighter-rouge">stan</code> for source-code level analysis.</p>
<p>For the Haskell ecosystem, we continue to work with past teachers and the best universities in Vietnam to find the best crops to train. These training are essential to the growth of the MELD engineering team. Nurturing the purely functional mindset should help us flourish on the functional blockchain Cardano as well.</p>
<h2 id="hachi">Hachi</h2>
<p><a href="https://medium.com/meld-labs/meld-announces-hachi-7b24b993487a">MELD Announces Hachi!</a></p>
<p>Hachi is our effort to develop a suite of security analysis tools for Plutus smart contracts. This project will be <a href="https://github.com/HachiSec">open-sourced</a> to the public eventually. For now, we focus on research and experiments on Cardano to better understand how to have the best approach for each problem.</p>
<p>Here is a summary of what we have done lately:</p>
<ul>
<li>Continue smart contract security research in general.</li>
<li>Continue to study Cardano architectures, Plutus interpreters, and more.</li>
<li>More static analysis research of functional programming languages & Lambda Calculus.</li>
<li>Refine and write more proposals & documentation. Go to greater lengths to plan the ambitious future of Hachi!</li>
<li>Write and review more contracts with vulnerabilities on Cardano.</li>
<li>Continue to extend internal Haskell libraries and tooling for security research.</li>
<li>Update Antlr4 grammar for Plutus Core.</li>
<li>Add VIM syntax highlighting for Plutus Core code.</li>
<li>Archive Hachi Lint for more powerful static analysis approaches like <code class="language-plaintext highlighter-rouge">stan</code>, and more.</li>
<li>Continue to build a foundation environment with a passive Cardano node, ChainIndex, script deserialization, and more.</li>
<li>Continue work to transform Plutus Core AST to XML for XPath queries.</li>
<li>Continue work to transpile Plutus Core to LLVM IR.</li>
<li>Symbex:
<ul>
<li>Convert more Haskell types to Racket.</li>
<li>Build symbolic <code class="language-plaintext highlighter-rouge">ScriptContext</code>s.</li>
<li>Support sum types & concrete-length lists including pairs.</li>
<li>Basic strategy on finalization to make sure programs terminate.</li>
</ul>
</li>
<li>UPLC Parser:
<ul>
<li>Improve pretty printing configuration.</li>
<li>Support string constants in addition to bytestrings.</li>
</ul>
</li>
<li>Continue to implement our own CEK machines.</li>
<li>Survey Cardano low-level FFI for security risks.</li>
<li>Survey Cardano web interfaces and endpoints for security risks.</li>
<li>Plan an auditing framework for Cardano dApps.</li>
</ul>
<p>We are writing a White Paper for Hachi to document the vision and projects. We hope to release the first draft next week to display the picture a lot clearer.</p>
<h2 id="adamatic">ADAmatic</h2>
<p><a href="https://medium.com/meld-labs/meld-presents-adamatic-7cfcfbb1f655">MELD and VENT Present ADAmatic!</a></p>
<p>We are very excited to announce that <a href="https://obsidian.systems/">Obsidian Systems</a>, one of the best Haskell consultants, a partner of IOG themselves, have joined to build the bridge with us. Many more partners are expected to join soon. The ADAmatic bridge has and will always be a community-driven project.</p>
<p>We have continued to complete the formal specifications of the bridge, to publish its first White Paper by the end of the month. The current focus is to lock ADA on Cardano and mint mADA on Polygon.</p>
<p>More concretely:</p>
<ul>
<li>Continuously survey the ecosystem on both ends to improve planning.</li>
<li>Seek more partners to co-build and run the bridge network.</li>
<li>A Proof-of-Concept bash script for the Cardano side for the “minting mADA” flow, i.e., have a user send ADA to a bridge-controlled address (with the sending transaction containing the desired target Polygon address), use <code class="language-plaintext highlighter-rouge">cardano-wallet</code> to list all the payments to the bridge including the target Polygon address.</li>
<li><code class="language-plaintext highlighter-rouge">cardano-node</code> and <code class="language-plaintext highlighter-rouge">cardano-wallet</code> running in CI, connected to the public Cardano testnet, with the above bash script running successfully against it.</li>
<li>Private Cardano testnet up and running successfully in CI. Write more tests in general.</li>
<li>Planning the database structure that will be used to coordinate the two sides of the bridge. E.g., minting mADA in response to locking ADA.</li>
<li>Nixify a Polygon node to deploy to Mumbai. This effort is still highly experimental.</li>
<li>Deploy the first mADA ERC20 contract on the Mumbai testnet. It simply has a mint function usable by the contract owner and the ability for holders of mADA to burn their tokens that emits an event for the bridge to pick up on.</li>
<li>Attempt to pick up Polygon events from Haskell instead of using PolygonScan or other JSON-RPC tools.</li>
</ul>
<p>Upon completion, we will have a solid foundation to sprint through:</p>
<ul>
<li>Burn mADA on Polygon to redeem ADA on Cardano.</li>
<li>Lock MATIC on Polygon to mint mMatic on Cardano.</li>
<li>Burn mMatic on Cardano to redeem Matic on Polygon.</li>
</ul>
<p>After which we can focus on completing the first governance setup for safelisted partners to run the bridge network; support more tokens; and eventually cross-chain contract integration with ChainLink, RenVM, and more.</p>
<h2 id="meld">MELD</h2>
<p><a href="https://meld.com">MELD.com</a></p>
<h3 id="smart-contracts">Smart Contracts</h3>
<p>Our focus has been innovating smart contract designs, optimizing output scripts, and early App integration. Here is the summary of progress:</p>
<ul>
<li>Continue to track Cardano’s progress and smart contract research in general.</li>
<li>Continue to refine protocol specifications and smart contract designs.</li>
<li>Continue to test the latest dependencies.</li>
<li>Continue to innovate new contract designs, like with brand new architectures, or with new features like redeemers in <code class="language-plaintext highlighter-rouge">ScriptContext</code>.</li>
<li>Continue to refactor code.</li>
<li>Continue to improve the current liquidation system.</li>
<li>Complete a prototype for a new lending model.</li>
<li>Complete the first liquidity pool prototype with the Concurrent & Deterministic Batching architecture.</li>
<li>Continue to work with the ChainIndex component for App integration.</li>
<li>Start deploying components to the testnet.</li>
<li>Develop more techniques to reduce script size, transaction size, and fees.</li>
</ul>
<h3 id="economics--tokenomics">Economics & Tokenomics</h3>
<p>Our focus has been designing dynamic interest rates, MELD incentive functions, and designing brand new economics models! Here is the summary of progress:</p>
<ul>
<li>Continue to study many DeFi protocols on many different blockchains.</li>
<li>More economics and tokenomics research, especially on interest rates, incentive functions, AMMs, derivatives, and futures contracts.</li>
<li>Collect more data to analyze, especially on DEX and lending protocols.</li>
<li>More in-depth market research.</li>
<li>Continue work on several forecast models on protocol usage, fees, MELD token’s value, and more.</li>
<li>Continue work for dynamic interest rates.</li>
<li>Continue work on MELD incentivization for lenders and borrowers.</li>
<li>Continue work to design better liquidity pools or better economics models in general with One-Shot markets.</li>
<li>Continue work on fiat (stablecoin) yield.</li>
<li>Start working on yield aggregation.</li>
</ul>
<p>It is still very early, but we now have real-life DeFi data to collect and analyze with the smart contract launch on Cardano mainnet. We have also onboarded a seasoned Quant/mathematician to further formalize and prove many of these works. This academic capability brings a lot more confidence to innovate. Do expect the first economics & tokenomics articles and draft papers soon!</p>
<h3 id="meldapp">MELDApp</h3>
<p>We have been facing a few integration problems that have slowed us down. We still hope to beta-test the MELDApp this month and release the first production version next quarter. Other than that, more intuitive demos are planned towards the end of the month to display core on-chain functionalities and interactions.</p>
<p>A summary of progress:</p>
<ul>
<li>Continue to scale the MELDApp team.</li>
<li>Continue to partner with more teams to build faster.</li>
<li>Continue to finalize the MELDApp, wallet, and API specifications.</li>
<li>Continue to complete UI/UX designs.</li>
<li>Complete the first AWS setup.</li>
<li>Complete the first Firebase setup.</li>
<li>Continue security operations.</li>
<li>Continue to implement and document MELDApp endpoints.</li>
<li>Continue to work on the frontend core and interfaces.</li>
<li>Continue to work on intuitive demos to demonstrate smart contracts.</li>
</ul>Concurrent & Deterministic Batching on the UTXO Ledger2021-09-09T16:59:59+00:002021-09-09T16:59:59+00:00https://meld-labs.github.io/technical/reports/2021/09/09/concurrent-deterministic-batching-utxo<h1 id="abstract">Abstract</h1>
<p>This paper presents an eUTXO smart contract architecture that allows concurrent and deterministic batching into a single state. Our solution is entirely deterministic, decentralized, and does not depend on honest or incentivized off-chain agents. While this paper uses batching swap orders into a liquidity pool on Cardano as the case study, the architecture should adapt to any frequently updated on-chain state on any UTXO blockchain that supports scripting. We hope this work will lead to a successful Cardano implementation and new smart contract architecture research in the future.</p>
<embed src="https://meld-labs.github.io/technical/assets/Concurrent_Deterministic_Batching_on_UTXO_2.pdf" type="application/pdf" style="width: 100%; height: 1000px;" />
<h1 id="conclusions">Conclusions</h1>
<p>This paper presented a general solution to the concurrency problem on UTXO ledgers, especially for on-chain states that require constant updates. The architecture is still in its early form. More specialized techniques are needed to scale different dApps further. We have, for example, been designing extended and different architectures for different MELD components.</p>
<p>We have a massive backlog of innovative ideas to explore and expect to publish many new versions and research efforts soon. It is now indeed the best time to do R&D on Cardano and the UTXO ledgers in general.</p>AbstractHachi’s First Day on Alonzo Purple2021-09-02T16:59:59+00:002021-09-02T16:59:59+00:00https://meld-labs.github.io/technical/reports/2021/09/02/hachi-first-day-alonzo-purple<h1 id="what-is-hachi">What is Hachi?</h1>
<p><img src="/technical/assets/hachi.png" alt="Hachi" /></p>
<p><a href="https://medium.com/meld-labs/meld-announces-hachi-7b24b993487a">MELD Announces Hachi!</a></p>
<p>Hachi is our effort to develop a suite of security standards and tooling for Cardano Smart Contracts. This project will be <a href="https://github.com/HachiSec">open-sourced</a> to the public eventually. For now, we focus on various research and experiments to better understand how to have the best approach for each problem.</p>
<p>MELD has been funding Hachi on our own, but we hope the community will join us to develop Hachi as a community-driven project. The road ahead is nothing but pure excitement and creativity!</p>
<h1 id="hachis-first-day-on-alonzo-purple">Hachi’s First Day on Alonzo Purple</h1>
<p>After nearly two months since Hachi’s inception, today is our first day on an Alonzo testnet! Before that, we spent more effort mastering Plutus Core, from its formal specifications, representations, compilation pipeline to the interpreters, cost models, etc. Another key focus is on Blockchain and Smart Contract Security in general. It is not trivial since Cardano has a unique tech stack, architecture and is still in the early days of Smart Contracts support. We’ve proposed over 20 different security tooling and service ideas and have been working hard to build a foundation for future research and development. We look forward to publishing our first Hachi White Paper in September. Stay tuned!</p>
<p>Back to the main topic, let’s go through our first day on Alonzo Purple.</p>
<h2 id="node-setup">Node Setup</h2>
<p>We have good experience building and running Cardano nodes, so it is relatively straightforward to set up Alonzo Purple. We compiled the node from source (<code class="language-plaintext highlighter-rouge">@57cbbc9c58b9bc9f3fc54c116b742d1c4be72e79</code>), get the config files, then set up a quick startup script:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>#!/bin/bash
NODE_CONFIG=testnet
DIRECTORY=~/MELD/${NODE_CONFIG}-node
TOPOLOGY=${DIRECTORY}/${NODE_CONFIG}-topology.json
DB_PATH=${DIRECTORY}/db
SOCKET_PATH=${DIRECTORY}/db/socket
CONFIG=${DIRECTORY}/${NODE_CONFIG}-config.json
cardano-node run --topology ${TOPOLOGY} --database-path ${DB_PATH} --socket-path ${SOCKET_PATH} --config ${CONFIG}
</code></pre></div></div>
<h3 id="chain-index">Chain Index</h3>
<p>While waiting for the node to sync, we continued to experiment with the new <code class="language-plaintext highlighter-rouge">plutus-chain-index</code> component for efficient script/datum/redeemer storage and queries for security research. To develop our Dapp, we have been following numerous Chain Index PRs from the IOHK team lately and become familiar with this codebase.</p>
<p>Testnet nodes sync quickly, so we left a quick PR improving CLI config handling before getting back to the synced node.</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3853">input-output-hk/plutus#3853</a></li>
</ul>
<p>The PR includes:</p>
<ul>
<li>Further distinguish chain index & logging configs.</li>
<li>Support print default configs to file.</li>
</ul>
<p>Previously there is an unhandled <code class="language-plaintext highlighter-rouge">DumpDefaultConfig</code> CLI command, with a few misdescriptions between the two config types.</p>
<p>We are going to write more about Chain Index in our Plutus documentation effort:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus/pull/3707">input-output-hk/plutus#3707</a></li>
</ul>
<p>We also made an attempt to introduce this component into <code class="language-plaintext highlighter-rouge">plutus-starter</code>:</p>
<ul>
<li><a href="https://github.com/input-output-hk/plutus-starter/pull/27">input-output-hk/plutus-starter#27</a></li>
</ul>
<h2 id="monitor-scripts--data">Monitor Scripts & Data</h2>
<h3 id="cardano-cli">Cardano CLI</h3>
<p>Coming back to the synced node, the first thing that came to our mind was to query data with <code class="language-plaintext highlighter-rouge">cardano-cli</code>.</p>
<p>We first checked the ledger state:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cardano-cli query ledger-state --testnet-magic 1097911063
</code></pre></div></div>
<p>Then look at the utxos:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cardano-cli query utxo --whole-utxo --testnet-magic 1097911063
</code></pre></div></div>
<p>We ran into an interesting error with <code class="language-plaintext highlighter-rouge">query utxo</code>:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cardano-cli: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character)
</code></pre></div></div>
<p>It looks like an encoding bug on the presentation side that has already been reported. We may open a PR to fix this issue later.</p>
<p>We continued with this <code class="language-plaintext highlighter-rouge">grep</code> that shows Datums, a hint that contracts have already been deployed!</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ cardano-cli query ledger-state --testnet-magic 1097911063 | grep 'datahash": "'
"datahash": "b1141c05ac58491c724c1b223ed01f7bca96ed7ea396c6f194b61d917b65b2d0",
"datahash": "8f42ba9d7761a7fad6198bffc4659c8be0d688b5a744a3fe2580f3e35f66d8a3",
"datahash": "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273",
"datahash": "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273",
"datahash": "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273",
"datahash": "4932dce28712ccc4858e3d83cc8e79b12740f66007dc9a287bb640a264c899de",
"datahash": "93978341ed4f41d3a7e7afa234e31c4e8cde68f54bd342885f421103c2c2ba02",
"datahash": "f10cf66e117391cd8c37494e5e6527e506cfdd176be72d6b396c68348a7a069e",
"datahash": "d70d3db4f4f2f9e3321d36c80ddfa9db32c3c2b210349ee21c52a1f02843ed91",
"datahash": "9ad30ffde0d1931ed4f145fa0a0d320a067051bfab1b08cbdb79e9f26df55df3",
"datahash": "93978341ed4f41d3a7e7afa234e31c4e8cde68f54bd342885f421103c2c2ba02",
"datahash": "93978341ed4f41d3a7e7afa234e31c4e8cde68f54bd342885f421103c2c2ba02",
"datahash": "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273",
"datahash": "8f42ba9d7761a7fad6198bffc4659c8be0d688b5a744a3fe2580f3e35f66d8a3",
"datahash": "a9be31977ee0a75de1efdeae66b3e49aabec3d20f61ac487d262a3a5aad28ba5",
"datahash": "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273",
"datahash": "9ad30ffde0d1931ed4f145fa0a0d320a067051bfab1b08cbdb79e9f26df55df3",
"datahash": "ebfe829ec8d2c43031b365765332b73268352e2a9e1db7fccb3be08490865c3c",
"datahash": "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273",
"datahash": "310be1f47c9d5bffc8de44cb930450ac2b82a82d3c7230f8f927b53a4d670087",
"datahash": "93978341ed4f41d3a7e7afa234e31c4e8cde68f54bd342885f421103c2c2ba02",
"datahash": "a23dee4ad091c8c4ffb93e16f8d90cf5a513952d136c88c0f17892338f8a206d",
</code></pre></div></div>
<p>We could see a reasonable number of similar scripts deployed to the Testnet on the first day of public Alonzo Purple.</p>
<h3 id="haskell-syncer">Haskell Syncer</h3>
<p>Since <code class="language-plaintext highlighter-rouge">plutus-chain-index</code> wasn’t quite ready yet, we quickly prototyped our own syncer to get scripts, datums, redeemers, and all important transaction data for security research.</p>
<p>We started from customizing this demo program:</p>
<ul>
<li><a href="https://github.com/input-output-hk/cardano-node/blob/master/cardano-client-demo/ScanBlocks.hs">input-output-hk/cardano-node/cardano-client-demo/ScanBlocks.hs</a></li>
</ul>
<p>The first thing to do is update the <code class="language-plaintext highlighter-rouge">socketPath</code> and <code class="language-plaintext highlighter-rouge">localNodeNetworkId</code> configs to match our node setup.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>- let socketPath = socketDir </> "node.sock"
+ let socketPath = socketDir </> "socket"
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>- localNodeNetworkId = Mainnet,
+ localNodeNetworkId = Testnet (NetworkMagic 1097911063),
</code></pre></div></div>
<p>We then pattern match only on Alonzo blocks for further processing:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>clientStNext =
ClientStNext {
recvMsgRollForward = \b _ -> ChainSyncClient $ do
case b of
BlockInMode block AlonzoEraInCardanoMode -> ...
-- ^ process the Alonzo block here!
...
</code></pre></div></div>
<p>We continue to pattern match on the <code class="language-plaintext highlighter-rouge">Block</code> with <code class="language-plaintext highlighter-rouge">Block _ transactions</code> then:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ShelleyTx ShelleyBasedEraAlonzo (Alonzo.ValidatedTx _ (Alonzo.TxWitness _ _ scripts datums redeemers) _ _)
</code></pre></div></div>
<p>For the transaction. Then for each script:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>(ScriptHash h, Alonzo.PlutusScript sbs)
</code></pre></div></div>
<p>We then store the script bytestring, relevant datums, and redeemers to local files for further queries. We can now track all deployed contracts that can be case studies for Hachi tools with this setup. This process will be further significantly improved with Chain Index.</p>
<h2 id="script-representation">Script Representation</h2>
<p>A Plutus script can be represented in many ways. On one end, we have the raw bytes found above. On another, we have the original high-level Haskell code. In security, finding what to do on which representation is an exciting endeavor filled with creativity. We should not analyze raw bytes directly as they are too unstructured for many techniques to operate on. At the same time, source code level analysis depends too much on a subset of large and diverse API designs and has to trust the compilation pipeline by default. It might not be easy to port Haskell-specific tools to new source languages in the future, either.</p>
<p>With that in mind, we have been experimenting on the more in-between representations, preferably on the low-end, for more precision. Here are a few we have worked on today.</p>
<h3 id="plutusv1ledgerscriptsscript">Plutus.V1.Ledger.Scripts.Script</h3>
<p>This is usually our first go-to representation, easily constructed from the script bytestring:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>bs <- BS.readFile script.raw
case scriptFromBytes (SBS.toShort bs) of
Left deserialiseErr -> ...
Right script -> ...
-- ^ This is what we want
</code></pre></div></div>
<p>With the following helper functions:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>deserialiseBytes ::
Serialise a => SBS.ShortByteString -> Either DeserialiseFailure a
deserialiseBytes = deserialiseOrFail . LBS.fromStrict . SBS.fromShort
scriptFromBytes ::
SBS.ShortByteString -> Either DeserialiseFailure Script.Script
scriptFromBytes = deserialiseBytes @Script.Script
</code></pre></div></div>
<p>We can then print the Untyped Plutus Core AST with:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>print (Script.unScript script)
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Program () (Version () 1 0 0) (Apply () (Apply () (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (Var () (DeBruijn {dbnIndex = 5}))))))) (Delay () (LamAbs () (DeBruijn {dbnIndex = 0}) (Var () (DeBruijn {dbnIndex = 1}))))) (LamAbs () (DeBruijn {dbnIndex = 0}) (Var () (DeBruijn {dbnIndex = 1}))))
</code></pre></div></div>
<p>We can also apply arguments to the script:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>let appliedScript = Script.applyArguments script [PLC.I 0x48656c6c6f21, PLC.I 2, PLC.I 3]
</code></pre></div></div>
<p>And evaluate the script, before or after argument application:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>case Script.mkTermToEvaluate s of
Left freeVariableErr -> ...
Right (UPLC.Program _ _ term) ->
print $ Cek.evaluateCekNoEmit PLC.defaultCekParameters term
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Right (Delay () (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 5}}) (Var () (Name {nameString = "", nameUnique = Unique {unUnique = 5}}))))
</code></pre></div></div>
<h3 id="pretty-print">Pretty-print</h3>
<p>We can also pretty-print a script with:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>print (pretty (Script.unScript script))
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>(program 1.0.0
[ [ (lam (lam (lam (lam (lam ))))) (delay (lam )) ] (lam ) ]
)
</code></pre></div></div>
<p>Which can get non-pretty quickly as the script gets more complex. For example, a Hello World program looks like this:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>(program 1.0.0
[
[
[
(lam
(lam
(lam
[
(lam
[
(lam
[
(lam
[
[
(lam
(lam
[
(lam
[
(lam
(lam
(lam
(lam
(force
[
[
(force
[
[
[ [ (force ) ] ]
(force )
]
]
)
(delay )
]
(delay [ (force ) ])
]
)
)
)
)
)
(delay
[
(builtin bData)
(con
bytestring
#48656c6c6f20576f726c6421
)
]
)
]
)
(delay
(lam
[
(force )
[ (force [ ]) (con unit ()) ]
]
)
)
]
)
)
(delay (lam ))
]
(lam )
]
)
(delay (lam (error)))
]
)
(lam
(lam
[
[
[
(force (builtin ifThenElse))
[ [ (builtin equalsData) ] ]
]
]
]
)
)
]
)
(delay (lam ))
]
)
)
)
(delay (lam (lam )))
]
(delay (lam (lam )))
]
(lam )
]
)
</code></pre></div></div>
<p>That said, pretty-printed programs are good source code for further transpilers and compilers, especially for small languages with concise specifications like Plutus Core. For example, as demonstrated in previous reports, we have been working on a Racket transpiler to utilize the more abundant tooling there. <code class="language-plaintext highlighter-rouge">plutus-core</code> also provides a few CLI programs like <code class="language-plaintext highlighter-rouge">pir</code>, <code class="language-plaintext highlighter-rouge">plc</code>, and <code class="language-plaintext highlighter-rouge">uplc</code> for interaction with this representation.</p>
<p>Previously we had little trouble working with pretty-printed code that we compile from Haskell. But today’s pretty-printed DeBruijn raw programs don’t seem to follow the formal specifications. To progress faster, we extended our transpiler to support printed Term AST from Haskell:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>case Script.mkTermToEvaluate s of
Left freeVariableErr -> ...
Right (UPLC.Program _ _ term) -> ...
-- ^ This term
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Apply () (Apply () (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 0}}) (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 1}}) (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 2}}) (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 3}}) (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 4}}) (Var () (Name {nameString = "", nameUnique = Unique {unUnique = 0}}))))))) (Delay () (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 5}}) (Var () (Name {nameString = "", nameUnique = Unique {unUnique = 5}}))))) (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 6}}) (Var () (Name {nameString = "", nameUnique = Unique {unUnique = 6}})))
</code></pre></div></div>
<p>We apply an empty <code class="language-plaintext highlighter-rouge">[]</code> to make a smaller term for the transpiler to work with:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Right (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 2}}) (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 3}}) (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 4}}) (Delay () (LamAbs () (Name {nameString = "", nameUnique = Unique {unUnique = 5}}) (Var () (Name {nameString = "", nameUnique = Unique {unUnique = 5}})))))))
</code></pre></div></div>
<h3 id="racket">Racket</h3>
<p>We have been developing a Racket transpiler with helper functions to evaluate the original Plutus Core programs and solvers to find data that bypasses the script in Racket.</p>
<p>Always True:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cat AlwaysTrue.term | hc
(λ (v2) (λ (v3) (λ (v4) (delay (λ (v5) v5)))))
</code></pre></div></div>
<p>Hello World:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cat HelloWorld.term | hc
(λ (v10) (λ (v11) (λ (v12) (force (((force ((λ (v24) v24) ((((λ (v19) v19) (λ (v17) (λ (v18) ((((force (ifThenElse)) (((equalsData) v17) v18)) (delay (λ (v20) (λ (v21) v20)))) (delay (λ (v22) (λ (v23) v23))))))) v10) ((bData) (bytes #x48 #x65 #x6C #x6C #x6F))))) (delay (delay (λ (v14) v14)))) (delay ((λ (v13) ((λ (v16) (assert #f "Validate failed")) ((force ((λ (v15) v15) v13)) unitval))) (delay (λ (v14) v14)))))))))
</code></pre></div></div>
<p>We use visual graphs of flattened ASTs to make it more human-friendly to reason about:</p>
<p><img src="/technical/assets/hellowworldast.png" alt="Hello World AST" /></p>
<p>We are still working to improve our transpiler and will write more about it soon.</p>
<h2 id="target-1-always-true">Target #1: Always True</h2>
<p><strong>DISCLAIMER</strong>: The following content is not actual exploitation. We will not publish vulnerabilities of non-trivial scripts but will try our best to report to related projects. Please do the same if you try to replicate or do something similar.</p>
<p>We now move onto our first exploitation experiment: The <strong>Always True</strong> script. It is a validator script that always approves transactions that spend its outputs.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>mkValidator :: BuiltinData -> BuiltinData -> BuiltinData -> ()
mkValidator _ _ _ = ()
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>(program 1.0.0
[ [ (lam (lam (lam (lam (lam ))))) (delay (lam )) ] (lam ) ]
)
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Program () (Version () 1 0 0) (Apply () (Apply () (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (LamAbs () (DeBruijn {dbnIndex = 0}) (Var () (DeBruijn {dbnIndex = 5}))))))) (Delay () (LamAbs () (DeBruijn {dbnIndex = 0}) (Var () (DeBruijn {dbnIndex = 1}))))) (LamAbs () (DeBruijn {dbnIndex = 0}) (Var () (DeBruijn {dbnIndex = 1}))))
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>(λ (v2) (λ (v3) (λ (v4) (delay (λ (v5) v5)))))
</code></pre></div></div>
<p>There are multiple ways to track the on-chain script. Our favorite thus far is to find the address from the on-chain script bytes. First, further serialize and write the script to an envelope:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>writeFileTextEnvelope @(PlutusScript PlutusScriptV1) "AlwaysTrue.plutus" Nothing (PlutusScriptSerialised (SBS.toShort bs))
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{
"type": "PlutusScriptV1",
"description": "",
"cborHex": "4e4d01000033222220051200120011"
}
</code></pre></div></div>
<p>We then get the on-chain address of the script:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ cardano-cli address build --testnet-magic 1097911063 --payment-script-file AlwaysTrue.plutus
addr_test1wpnlxv2xv9a9ucvnvzqakwepzl9ltx7jzgm53av2e9ncv4sysemm8
</code></pre></div></div>
<p>Then we find the target utxos:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ cardano-cli query utxo --testnet-magic 1097911063 --address addr_test1wpnlxv2xv9a9ucvnvzqakwepzl9ltx7jzgm53av2e9ncv4sysemm8
TxHash TxIx Amount
--------------------------------------------------------------------------------------
22909f2a82cdf271cc09824f8f2082910553694d33fae9c8d75abba22b4a8fb9 1 150000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "b1141c05ac58491c724c1b223ed01f7bca96ed7ea396c6f194b61d917b65b2d0"
4ad1845d3a5cb6cce7d166caca7c7dcd139fa0aa832656fac798e422da3fcdf0 1 10000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "a23dee4ad091c8c4ffb93e16f8d90cf5a513952d136c88c0f17892338f8a206d"
5f2ef2880f24a1111b7e9474e5e3b11c15538000052904e2d8c022e8de5e06e7 0 770000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"
6b439ca8bdb069d7d7bc203ba5b61c2b27ff8c6cca4767864860ea11120c0db8 0 770000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"
a21766d6f0a6ce93386243217329cffdbcb1e1f8c291fa2a0c4b2132c0b62dee 1 1000000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"
a6752e5260757103cfa63f8346f3e5c705523c24fef443cea850dc6316e85fa3 1 1000000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"
d1afee56aecb50b4ba7d5ced38ca92f43a2c17af443867a9aa9b0b2847d40377 0 770000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"
e56089a6c1f6e18bb8b22f17970938004797b4ee5dcf55da547d639b83015634 0 770000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"
e70da16d28c4ba234498b2c6222284076a88bab94d7223f1a27ff1f597308454 0 770000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"
edebfe352ef225edf03fe254ae26141c45b530478d4353db45aa28c4eea1acde 0 16661337 lovelace + TxOutDatumHashNone
f852223988fba77af7752c8edad4203ffb19a0472b62e59ceff7ddb39877a9aa 1 20000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "310be1f47c9d5bffc8de44cb930450ac2b82a82d3c7230f8f927b53a4d670087"
</code></pre></div></div>
<p>We can easily see the repeated <code class="language-plaintext highlighter-rouge">770000000 lovelace + TxOutDatumHash ScriptDataInAlonzoEra "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273"</code> entries here, which is indeed our first target.</p>
<p>From our syncer, we can see that the Datum of these is:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>TxDatsRaw (fromList [(SafeHash "fcaa61fb85676101d9e3398a484674e71c45c3fd41b492682f3b0054f4cf3273",DataConstr Constr 0 [I 42])])
</code></pre></div></div>
<p>And below is the redeemer:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>RedeemersRaw (fromList [(RdmrPtr Spend 0,(DataConstr Constr 0 [I 42],ExUnits {exUnitsMem = 1700, exUnitsSteps = 476468}))])
</code></pre></div></div>
<p>So a withdrawal transaction can be set up quite easily:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>export TARGET_UTXO=5f2ef2880f24a1111b7e9474e5e3b11c15538000052904e2d8c022e8de5e06e7#0
export COLLATERAL=b9d171e1c7109a11fefa72b5c2eeb5555f00e153ddbe37a28bef61a7cd1f20d0#0
cardano-cli transaction build \
--alonzo-era \
--tx-in ${TARGET_UTXO} \
--tx-in-script-file original.plutus \
--tx-in-datum-file typed-42.json \
--tx-in-redeemer-file typed-42.json \
--tx-in-collateral ${COLLATERAL} \
--change-address $(cat payment.addr) \
--protocol-params-file pparams.json \
--testnet-magic 1097911063 \
--out-file tx.raw
</code></pre></div></div>
<p>We initially had some trouble with the JSON encoding of Plutus Core Data. <code class="language-plaintext highlighter-rouge">DataConstr Constr 0 [I 42]</code> is elementary to read and construct in Haskell. But we had no idea how to get the correct JSON, with <code class="language-plaintext highlighter-rouge">cardano-cli transaction hash-script-data</code>, <code class="language-plaintext highlighter-rouge">--tx-in-datum</code>, and <code class="language-plaintext highlighter-rouge">--tx-in-redeemer</code> all require data in JSON format. After a few minutes we got bored with the trial-and-errors and just searched the pattern online, to find the source at <a href="https://github.com/input-output-hk/cardano-node/commit/f1cbf4e209b58f22213e0cbc2b862daabda353d2">input-output-hk/cardano-node@f1cbf4e209b58f22213e0cbc2b862daabda353d2</a>. We then learned the correct way in <a href="https://github.com/input-output-hk/cardano-node/blob/master/scripts/plutus/data/typed-42.datum">input-output-hk/cardano-node/scripts/plutus/data/typed-42.datum</a>:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{"constructor":0,"fields":[{"int":42}]}
</code></pre></div></div>
<p>We tried a different one in:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>TxDatsRaw (fromList [(SafeHash "4932dce28712ccc4858e3d83cc8e79b12740f66007dc9a287bb640a264c899de",DataConstr I 1337)])
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>RedeemersRaw (fromList [(RdmrPtr Spend 0,(DataConstr I 42666,ExUnits {exUnitsMem = 2500, exUnitsSteps = 1993190}))])
</code></pre></div></div>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>export TARGET_UTXO=741c9ac1df066995ee52d00492bd825f220f883ce3e459dea18d4dd60256e52d#0
cardano-cli transaction build \
--alonzo-era \
--tx-in ${TARGET_UTXO} \
--tx-in-script-file original.plutus \
--tx-in-datum-value 137 \
--tx-in-redeemer-value 42666 \
--tx-in-collateral ${COLLATERAL} \
--change-address $(cat payment.addr) \
--protocol-params-file pparams.json \
--testnet-magic 1097911063 \
--out-file tx.raw
</code></pre></div></div>
<p>And again, we withdrew the fund successfully. We then called it a decent first day on Alonzo Purple and finalized it with this blog.</p>
<h1 id="whats-next">What’s Next?</h1>
<p>We still have a lot of work to do and explore.</p>
<ol>
<li>Continue to analyze deployed scripts on the public testnet. We’re eyeing the Hello World, Guess Game, and a few Oracles and DEXes out there. It’s fascinating to see brand new Datum structures now and then!</li>
<li>Keep monitoring the progress of <code class="language-plaintext highlighter-rouge">plutus-chain-index</code> and help when possible. All for a stable and efficient syncer/DB for security work.</li>
<li>Continue to deep dive into Plutus, further inspect the problem with pretty-printed raw DeBruijn programs, offer help if appropriate.</li>
<li>Continue to deep dive into the current Plutus interpreters. Find vulnerabilities in the interpreters (a sane way to bypass even the <code class="language-plaintext highlighter-rouge">AlwaysFails</code> validator script). Plan instrumentation support for fuzzers. Offer help when appropriate.</li>
<li>Continue to push the Racket transpiler, interpreter, and all the tooling and techniques on that end. With other sub-projects like Hachi Lint, static analysis with XML trees & XPath.</li>
<li>Continue to ponder on the Bounty Program from the Cardano Foundation.</li>
<li>Write and publish more White Papers and technical reports.</li>
</ol>What is Hachi?