Weekly Report 2021/08/22

We build MELD on top of the Cardano blockchain, so improving the platform is one of our priorities. This weekly report gives some insights into our contribution to the Cardano ecosystem and the progress of our internal projects.

Plutus

Documentation

We have been spending a good amount of effort to help update Plutus documentation, which is usually outdated due to lightning development progress. One can never get enough good documentation. The whole community needs this!

This past week we continued to work on some documentation:

This week includes outlining a new section 5 – Goguen: Cardano Ledger for Smart Contracts in the EUTXO specs:

  • Relevant protocol parameters for DApp developers:
    • maxTxExUnits.
    • maxBlockExUnits.
    • maxValSize.
    • coinsPerUTxOWord.
    • collateralPercent.
    • maxCollInputs.
  • Phase-1 vs Phase-2 script terms.
  • The term “language”. Running scripts in all languages should be supported indefinitely.
  • More on cost models.
    • ` ExUnits`.
    • CostModel.
    • Prices.
    • Collateral inputs.
    • How everything comes together.
  • More on minting policies.
  • Transaction structure:
    • Mention why is txOutDatumHash a Maybe.
    • Introduce ScriptPurpose.
    • Introduce ScriptTag.
    • Introduce RedeemerPtr.
    • redeemerHash not in InputInfo.
    • thisInput & mintScripts not in Context.
    • dcerts, wdrl, signatures, infoId in Context.
    • validityInterval is not in Slot anymore, but in POSIXTimeRange.
    • Define TxInfo and Tx. How much should a DApp developer care for?

With more ongoing proposals:

  • Unify the terms “Quantities” (in specs) & “Value” (in code)?
  • Unify the terms “currency id” & “currency symbol”?
  • Update and write more Plutus Core specs & docs.
  • Proofread the rest of the papers.
  • Proofread and continue to write each module’s README.
  • Write more about PAB (critical to any dApp work).
  • Write more about the compilation pipeline & evaluators (critical to Hachi work).

Chain Index

We’ve been customizing the Chain Index component since early May! The point is to define our own cache structures for App-specific data, which then enables efficient GET endpoints.

This includes modifying up to 7 files for each new endpoint:

  • (Optional) Introduce a new script with new interesting Datum types to cache and fetch.
  • (Optional) Define new Front types for new Datum types, with a ToJSON instance for HTTP responses.
  • Add a new ChainIndexEffect to plutus-contract/src/Wallet/Effects.hs.
  • Add a new endpoint to plutus-pab/src/Cardano/ChainIndex/API.hs.
  • Add the new endpoint to plutus-pab/src/Cardano/ChainIndex/Client.hs.
  • Add a new endpoint to plutus-pab/src/Cardano/ChainIndex/Server.hs.
  • Implement the actual effect in plutus-contract/src/Wallet/Emulator/ChainIndex.hs.

We had gone so far that we wrote our own error handling infrastructure for Chain Index! This led to this unmerged PR, where we attempted to bring a simplified and modular part of it back to upstream.

Lately, we’ve been following the progress of the new standalone plutus-chain-index package. The new leaner design of the component is very nice. We can’t wait to integrate and customize it for MELD!

The past week we’ve also tried to rebased, fixed conflicts, and done more experiements with the new chain syncing part. It hasn’t worked yet, but it was still worth it! We do wish the Plutus team all the best on this front and are ready to join hands any time.

In the meantime, we’ve attempted to update plutus-starter to a fuller PAB setup, which does include the current Chain Index component. We hope this effort exposes the wonderful component more to the community. And that this fuller PAB setup will be helpful for more people in other situations as well.

Our future goals include making it more convenient to customize and extend this component for end developers and improving its performance for scalability.

Haskell ecosystem

GHC

Errors as (structured) values

This is an instrumental body of work. 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 to HLS, HLint, and hopefully Hachi Lint too!

Our first GHC PR that converts diagnostics in GHC.Tc.Validity to proper TcRnMessage:

We’ve done 4 errors last week and covered a ton more this past week:

  • TcRnUserTypeError is an error that occurs whenever a type signature mentions TypeError blah in it.
  • TcRnConstraintInKind whenever a constraint is specified in a kind.
  • TcRnUnboxedTupleTypeFuncArg whenever an unboxed tuple type is specified as a function argument.
  • TcRnLinearFuncInKind whenever a linear function is specified in a kind.
  • TcRnForAllEscapeError whenever a quantified type’s kind mentions quantified type variable.
  • TcRnVDQInTermType whenever a visible dependent quantification is specified in the type of a term.
  • TcRnIllegalEqualConstraints whenever an illegal equational constraint is specified.
  • TcRnBadQuantPredHead whenever a quantified predicate lacks a class or type variable head.
  • TcRnIllegalTupleConstraint whenever an illegal tuple constraint is specified.
  • TcRnIllegalPredConstraint whenever an illegal constraint is specified in a predicate.
  • TcRnNoneTypeVarArgInConstraint whenever a non type-variable argument is specified in a constraint.
  • TcRnIllegalImplicitParam whenever an illegal implicit parameter is specified.
  • TcRnIllegalConstraintSynonymOfKind whenever an illegal constraint synonym of kind is specified.
  • TcRnIllegalClassInst whenever a class instance is specified for a non-class.
  • TcRnOversaturatedVisibleKindArg whenever an illegal oversaturated visible kind argument is specified.
  • TcRnBadAssociatedType whenever a class doesn’t have an associated type.
  • TcRnForAllRankErr whenever an illegal ranked type is specified.

This also led to some extra work:

  • Pretty print suggest-extensions hints: remove space before interspersed commas.
  • Tc.Validity: Refactor Rank’s MonoType constructors. Each MonoType constructor should represent a specific case. With the Doc suggestion belonging to the TcRnMessage diagnostics instead.
  • Add GHC.Tc.Types.Validity with Rank from GHC.Tc.Validity. We needed this to include Rank in TcRnMessage. We first went the Validity.hs-boot route that added hundreds of module dependencies to Syntax and Parser hence a hard revert, to bring Rank to a new module instead. For more context see ghc#19932.

Echo from last week, but we do hope to complete the rest in the upcoming week.

More references:

HLint

We continue to study and contribute to HLint, which is critical to the development of Hachi Lint and to the output of the Errors as (structured) values GHC work above.

This past week we’ve mainly focused on reading HLint’s structure and coverage. With some time to continue trimming irrelevant parts in the hint outputs:

ormolu-action

We helped bump ormolu-action on Github while extending our Contract Code Standards:

MELD team will keep on expanding our R&D within the Cardano & Haskell ecosystem. More updates on this area will follow soon. Stay tuned!

Hachi

MELD Announces Hachi!

Hachi is our effort to develop a suite of security analysis tools for Plutus smart contracts. This project will be open-sourced 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.

Here is a quick summary of what we have done this week:

  • Continue smart contract security research in general.
  • Refine and write more proposals. Rearrange the execution order.
  • Write and review more contracts with vulnerabilities on Cardano.
  • Continue to plan and document Hachi Lint’s direction. Explore more static analysis techniques in general.
  • Continue to transpile Plutus Core to more representations.
  • Continue to implement Plutus Core builtins in Racket.
  • Write more internal tools. Improve transformation passes to make working with Plutus Core more pleasant.
  • Explore SMT engines and more techniques that apply to higher-order logic.
  • Start some initial fuzzing work.
  • Some early work on static analysis on Plutus & PLC code level.

Even though most work is still highly experimental, we hope to start demoing things soon. For now here is an animation trimming and flattening a Plutus Core AST from our transpiler work:

Please stay tuned for more!

ADAmatic

MELD and VENT Present ADAmatic!

We continue to focus on the architecture and specifications of the bridge. We’re expecting to onboard and announce more partners soon to both build with us and run the ADAmatic nodes to decentralize power. Cross-chain contract integration is still being studied (especially the RenVM study case), but the initial focus is still on the wrapping/MELDing assets functionality.

V0: Chi 地 V1: Atsu 圧
ADAmatic v0 ADAmatic v1

MELD

MELD.com

Smart Contracts

  • Onboard 2 new Blockchain engineers!
  • Finalize the first Smart Contract Standards for protocol specs, contract design, code quality, dependency management, CI/CD, and more.
  • Refine and extend CI pipelines to guarantee standards on several code bases.
  • Continue to study Ledger and Plutus documentation and codebase.
  • Continue to study more DeFi projects.
  • More PAB and Chain Index integration work.
  • Continue specification and contract design work with more test cases. Our focus has been on contract designs that balance concurrency and complexity (around the number of outputs for complex scripts, etc.).
  • Start building a sane framework for engineers and Quants to collaborate on designing and implementing DeFi economics & tokenomics models.

Tokenomics & Economics

  • Collect more data to analyze.
  • More in-depth market research.
  • More economics and tokenomics model research, especially on the mathematical models behind liquidity pools.
  • Write more in-depth analysis on liquidity pools, DEX and data sources.
  • Forecast protocol usage and traffic to estimate treasury release schedule, protocol fees, insurance solvency, staking APY, and more.
  • Continue token distribution and release schedule work. The team, advisors, and partners now start vesting 9 months after genesis!
  • Continue to study more DeFi projects.

Our biggest problem at the moment is the lack of data to analyze. Especially on Cardano, where concrete on-chain contract fees and liquidity/trading volumes haven’t been captured. The focus now is to complete the frame of the economics model, build a solid simulator then hardcore data collection and analysis. Then keep iterating to improve the model.

We’ve been picking up speed and talking to many awesome Quants lately. We’ll have separate economics reports and articles when things get stable enough, and hopefully many economics Yellow Papers too!

MELDApp

We’ve been making good progress with the ISPO dashboard and MELDApp in general. The Croatian team has been overloaded with the tight roadmap, so we don’t want to trouble them much at the moment. Beautiful displays will come soon enough.

We’re also looking to onboard partners and third-party integration instead of trying to build too much ourselves. The plan for the MELDApp is still to do public beta testing this quarter and release the first production version next quarter.