Last year, I was extremely excited to hear about the launch of Rue, a new programming language for Chia puzzles. Like Chialisp, Rue has a compiler that transforms ‘human-friendly’ code into CLVM bytecode, which is what gets executed when coins are spent on Chia. If you’re interested in more of the inner workings of the compiler, Rigidity’s blog has some great articles on the topic.

I am always looking to improve the quality (and timeline) of my Chia projects, so I decided to give Rue a try for the three main initiatives that I was working on: the Reward Distributor, XCHandles, and CATalog. All of them were already pretty far along, which allowed me to compare the existing Chialisp code directly to its Rue equivalent. Below, I (quite subjectively) compare the two languages in terms of the features I consider to be the most important: efficiency, developer experience, and security. While I tried noting the biggest nuances/caveats in the differences, I believe it’s best to take this with a grain of salt and form your own opinion - let me know your take in the comments!

Efficiency

It’s usually difficult to quantify the efficiency of programs in a way that captures all dimensions, but, thankfully, the Chia blockchain provides a ‘standard’ way through execution cost. Put simply, cost quantifies the computational resources - storage, execution, and changes to the blockchain - required to spend some coins. It is synonymous with a transaction’s size, and has a direct role in determining which transactions are prioritized (farmers essentially try to maximize fee-per-cost when building blocks). You can learn more about cost here and here.

As I had been working on the Reward Distributor/XCHandles/CATalog for a while, all projects already had tests covering all their features set up. In fact, one of the classes I added to the Chia wallet SDK is the benchmarker, which allows developers to easily label spends sent to the simulator during tests and later see statistics about spends with the same labels - to be more specific, their number and average/median/maximum/minimum costs. I added Benchmark specifically for action layer dApps, as I was curious about the throughput they support - the number of interactions in a block is inversely related to the cost of said interactions.

Here, I think the numbers speak for themselves. For each tested action (except setup, which was used as a control), bytecode generated by the Rue compiler had less cost than the Chialisp-generated equivalent. To quantify, all values were in the 93.13%-98.21% range, with an average relative cost of 95.91% and a median of 95.92%. Put another way, on average, using Rue saved 4.09% of the final bundle’s size, and in all examples Rue generated less costly (‘more efficient’) programs than Chialisp. The full data can be found here.

While 4.09% may seem like a low number, keep in mind that this cost difference is for fundamentally equivalent puzzles. Users of these dApps would pay, on average, 4.09% less in fees under fee pressure conditions. To me, this is an impressive improvement, as the Chialisp puzzles used for comparison have gone through multiple rounds of (sometimes esoteric) optimizations. What’s more, testing bundles were made to be similar to user interactions, which means they contain adjacent coin operations such as NFT transfers and offers - this makes relative cost decreases look worse than they actually are. If we are to believe the official cost estimates table, each spend bundle had almost the equivalent of one standard transaction removed from it in terms of cost (on average).

So, where does the cost difference come from? The Rue and Chialisp puzzles I compared are functionally equivalent, so they will have the same condition cost, as they output the same conditions. Thus, the difference comes from a mix of storage and execution cost. While future compression initiatives will minimize cost due to on-chain storage for puzzles, I can confidently say that, right now, a puzzle’s size makes up for a majority of its cost, and I predict that will be the case in the short and medium terms as well. A nice property of size is that you can record it directly from puzzles without any noise (coming, for example, from other puzzles running in the same spend bundle).

The Rue compiler removed 10 to 231 bytes from each of the 39 puzzles used in this small experiment. As a percentage, the range is 6.08% to 29.59%. The average number of bytes saved per puzzle is 110.72 (14.84%), and the median is 117 bytes (13.58%). You can find the raw data on the ‘Bytes’ tab of the spreadsheet linked above.

The regression line in the graph above suggests that the savings from switching to Rue can be approximated quite well using the equation of a line. There is an absolute saving, which I believe comes from Rue’s implementation of a frequently used Chialisp function, curry_tree_hash. Rue’s standard library uses an implementation that is significantly smaller but has a higher runtime cost, while the version used in Chialisp prioritizes runtime at the expense of a much larger storage footprint. An absolute saving of 32.2 bytes (387.600 cost) is indeed very close to the differences observed in the Chialisp vs. Rue curry benchmarks.

The slope of the regression line suggests that the Rue compiler also has a proportional advantage: each byte produced by Chialisp ‘corresponds’ to 0.9 bytes produced by Rue. This number likely comes from a few of the compiler optimizations Rue has that Chialisp hasn’t implemented, such as:

• Type checking (‘is’) simplification: If the type of a checked variable is already known, the check will be evaluated and replaced with the resulting boolean at compile time

• Symbol grouping: If multiple bindings (‘let’) are declared in the same code branch, the compiler tries to group definitions together to minimize the number of apply operators used in the resulting bytecode

• Symbol inlining: If a variable or constant is used a single time, its value will be inlined. Similarly, if a function is called a single time and its arguments are used a single time as well, it will be inlined automatically.

• Superpaths: The compiler detects when two or more references being concatenated could be replaced by a reference to an intermediary tree node (e.g., (c 2 3) -> 5) (hey, I suggested this one!)

• Binary tree arguments: The compiler structures the arguments of some functions as trees instead of lists, which makes referencing them take fewer bytes in some cases (hey, I suggested this one as well!)

Verdict: Rue > Chialisp, for now. There is no magical reason why the Chialisp compiler can’t implement Rue’s optimizations, but so far it hasn’t.

Note: All the puzzles in this benchmark use the ‘standard’ version of Chialisp for efficiency purposes. Puzzles in modern Chialisp, while easier to write due to QoL improvements such as ‘let,’ tend to take up a lot more bytes. There are plans to adapt the normal optimizer for modern Chialisp as well once it is ‘properly’ released; for this comparison, I used using the version that generates the most efficient puzzles.

Developer Experience

I believe one of Rue’s biggest advantages is readability - the ability of another developer to scan the code and understand what it does easily. Not only does this make collaboration and audits faster, but it also accelerates the development process itself. Particularly, I find Chialisp’s parenthesis structure to take some cognitive load during development, which Rue eliminates through the use of Rust-like syntax. Another thing I had to keep in mind during the experiment is that ‘standard’ Chialisp does not have let, but that is fixed in modern Chialisp, so I won’t take it as a factor.

Speaking of cognitive load, formatting code is also something that could be automated. This is not available for any of the two languages, but brings us to another category: tooling. Both languages have syntax highlighting, but I found the Chialisp extension to be extremely unreliable while modifying the code live (to the point where I just disable it since it’s better than seeing some portions highlighted while others aren’t). Rue, on the other hand, has an extension that works great and is mostly stable (works consistently, with only rare, non-reproducible edge cases). Another nice feature of Rue is that you can write test functions in the same file with Rue code - this is similar to what foundry does, and I expect it will become a very popular method of testing functions. Still, because the 3 apps I used were initially written in Chialisp (which does not have such features out-of-the-box), the benchmark code was written in the wallet SDK, which has greatly improved developer experience on Chia but is not part of the Rue language itself. One integration worth mentioning is compile_rue!, which allows developers to test the latest version of their code without having to compile, then copy the bytecode and hash during development (it’s similar to fast refresh for Next - change the code, and, the next time you run your test, the new bytecode/hash will be used).

Lastly, this post wouldn’t be complete if this section didn’t talk a bit about AI. In general, I am opposed to using AI as the primary way of writing on-chain code, which is responsible for managing user funds - if we want this industry to be taken seriously, we should treat critical code much more carefully than we treat UI code controlling how round an edge is. That said, I am all for using AI to complement reviews/audits/bug bounties/contests/etc. Generally, AI models were able to generate Rue completions very well, with the worst suggestions being in the places where they needed to rely heavily on Chia blockchain specifics (e.g., output conditions such as SEND_MESSAGE). For Chialisp, my usual workflow is to disable suggestions entirely - even with many puzzles in the codebase giving the models some of the syntax, suggestions are still terrible, and many times models try to use LISP operators. Ultimately, I think you can finetune models to be better for either language, but their current comprehension and ability to suggest good completions indicate that Rue may be much more ‘intuitive’ for programmers transitioning to Chia on-chain programming. That is, model performance on completions is a good proxy for how beginner friendly a programming language is.

Verdict: Rue >> Chialisp. Rue’s readability and beginner-friendliness cannot be easily copied by Chialisp, unlike its nice chia-wallet-sdk integration and testing suite.

Security

When it comes to on-chain programs, security is, in my opinion, the most important consideration. An easy way to compare languages is to ask, “How used is this in production?” Here, Chialisp takes the lead, but I predict Rue will quickly catch up due to it beating Chialisp in the other two categories (and stl agrees, see #6 here).

Another aspect is how syntax makes developers think and consider attack scenarios. An example from other ecosystems is Solidity, where re-entrancy vulnerabilities are easy to introduce if you’re not aware of them. I think that the architecture of the Chia blockchain inherently makes developers consider side-effects the same way for both languages, as they’re are all determined in the output condition list (e.g., create a coin).

A more nuanced question to ask is, “How likely is it that the code that I’m reading is doing what I think it’s doing?” Here, I think Chialisp has an advantage, as it seems a lot closer to CLVM than Rue, especially when it comes to the type system. For example, Rue’s type checks (e.g., assert var is Bytes32) rely on the compiler’s inferred types, which are not always enforced strictly in the final bytecode (for the arguments of the main function, for example). While I understand why Rue avoids the storage/runtime overhead for these checks, not understanding how the compiler handles types may create issues. That said, I believe Rue’s type system prevents a lot of errors, some of which may result in security vulnerabilities - while not ideal, I am convinced this is better than Chialisp’s lack of a type system.

Lastly, I’d like to point out that both compilers are well-tested in some way or another, and, while there’s always the chance the compiler introduces vulnerabilities by mis-translating code to bytecode, I think the chances for both Rue and Chialisp are minimal given the teams’ attention to security and the precautions in place.

Verdict: Chialisp > Rue, for now. I believe the gap between Rue and Chialisp will mostly disappear as more puzzles written in Rue reach production deployment.

Conclusion

There are two types of differences between Rue and Chialisp. Some of them are addressable - although Rue has an upper hand despite being more recent, Chialisp tooling and its optimizer can be improved. Likewise, Rue can (and likely will) get more ‘real-world’ testing as the protocols using it go live and grow in TVL.

The remaining differences go deeper. In my mind, there is one root cause for them: Rue is ‘further away’ from CLVM than Chialisp is. This makes it beginner friendly and generally much easier to read, but introduces the risk that developers might misinterpret the behavior of the compiler in some places, as Rue’s compiler has to make more complex decisions.

Personally, I think Rue’s advantages currently make it a better choice than Chialisp, and I predict this will be the case in the short/medium-term as well. I’m confident that Rue is well-tested, and my code was ultimately reviewed by the creator to ensure no compiler ‘edge cases’ were triggered by the puzzles. Still, it remains as important as ever to follow the latest developments in Chia tooling and programming languages, which may tilt the balance quite rapidly.

Special thanks to Rigidity and stl for making suggestions on a draft of this article.

CAT Precision

On Ethereum, ERC-20 tokens usually have 18 decimals, likely taking inspiration from Ether (1 ether = 10^18 wei). Chia’s designers have chosen 12 decimals for XCH, but were met with a small issue when developing the Chia Asset Token (CAT) standard: for CATs to work in the coinset model, they would have to lock up small amounts of XCH (usually measured in mojos, 1 XCH = 10^12 mojos). The precision tradeoff they faced can be put as follows: giving CATs too many decimals means significant XCH needs to be locked up to mint the said CATs. If you give your CAT a precision of 12, you need to lock up a whole XCH to mint one CAT token. Giving your CAT too few decimals, on the other hand, might make it harder to use as the CAT can be broken down into fewer pieces. Ultimately, CATs now have 3 decimals, meaning the smallest non-zero CAT unit you can hold is 0.001.

Note that this is more of a social convention for UIs: in reality, every CAT you hold is a coin with a special puzzle and a value of cat_amount * 1000 mojos.

Reward Distributors and Precision

As I previously mentioned, reward distributors were heavily inspired by the math behind liquidity farms. In short, the distributor syncs when someone interacts with it and calculates how many tokens should be distributed for the last period based on state data. Given the title and introduction of the article, it’s natural to ask what happens with the ‘remainder’ that can’t be distributed for a period. For example, if 10,000 NFTs are staked and the distributor needs to allocate 10.001 DIG, what happens with the 0.001 DIG?

The worst fate the 0.001 DIG could have is to be discarded, as that means no one will ever get it. This has, of course, been the main concern around the formulas during puzzle development and review - and can’t happen for reward distributors. In the current puzzle, the distributor, like liquidity farms, allocates the 0.001 DIG to the remainder of the epoch. Essentially, the reward rate is slightly boosted so the 0.001 DIG is allocated to someone eventually.

This approach works fine for ERC-20 tokens because they have so many decimals that the remainder is an extremely small error that’s irrelevant in practice. On Chia, however, this becomes a relevant issue because the smallest unit is 0.001 DIG. In practice, 87,500 DIG per year means that roughly 0.001 DIG will be given to every staked NFT every hour. If someone syncs the distributor every few minutes - like everyone did during the first days, when users rushed to stake their NFTs - the 0.001 DIG per NFT will be pushed later and later into the epoch. Staked NFTs then had a reward rate of around 0 DIG per day during high-activity days, a relatively normal reward rate for low-activity periods that spanned hours, and will have a much higher reward rate towards the end of the epoch, when all the accumulated ‘postponed’ rewards will get distributed.

More generally, the smallest unit of distribution takes a while to be assigned to every NFT, and syncing smaller intervals leads to rewards being ‘postponed.’ Done often enough, someone can make the reward allocation rate slower over some periods. In turn, other periods will have a higher rate to compensate.

What This Means for Minion Holders

Extreme care was put into ensuring that rewards are not lost. Stakers will still get the 8.750 DIG per minion per year they’re owed (assuming all NFTs are staked - otherwise, the number will be higher). However, the rate at which DIG is assigned will vary based on how often people interact with the distributor.

Next Steps

The current reward distributor puzzles will be updated to fix this issue. At a high level, the new version of the distributor will have a higher internal precision for CATs. This precision will be ‘stripped’ just before payouts. The update will allow the correct distribution of small fractions of 0.001 DIG if sync operations are done for short time intervals, effectively leading to the same behavior observed on Ethereum, where the postponed reward amounts are so small they are not practically relevant.

Lessons Learned

This design flaw was still caught during testing, but I believe there are ways to catch these kinds of limitations earlier. A few suggestions include:

• When designing puzzles, continuously ask yourself how the differences between Chia and the other systems where the mechanism was implemented may lead to unexpected behavior. Note that ‘behavior’ extends past security issues such as the loss of funds.

• Test under real conditions. As part of early development, the distributor puzzles were tested on a simulator. The tests included scenarios with one or a few NFTs staked over short periods of time. The problematic precision behavior would’ve been detected if the tests included more realistic or extreme scenarios (e.g., test distribution when 10,000 NFTs are staked and 50,000 test CATs are distributed over 10 years, with someone interacting with a distributor every few minutes).

• Broader reviews/audits: Instead of strictly looking for ways funds could be lost, the main question in a review or audit should be “What can someone do to make the behavior of the system deviate from what’s expected?”. This requires the purpose of the system to be well-defined in advance, and for the specification to be very verbose.

• Documenting common issues: By posting about this issue, the hope is that other developers will have it on top of their mind when designing similar systems in the future.

Conclusion

Lastly, let me extend a big thank you to everyone that has helped with testing so far. As you can see, these tests provide vital feedback that will improve the final version of the DIG Network.

You can find more about the DIG Network at dig.net.

How to Avoid a Lot of Transactions

Believe it or not, there was a time when the concept of staking tokens did not exist at all. The naive approach to distributing tokens to stakers - calculating and sending rewards every second or block - required a lot of transactions to be made very frequently. Implementing a liquidity farm with this approach was simply too expensive for any protocol, even with relatively few users. Scaling would also be impossible, as the transactions from only one farm would probably exceed block size limits after reaching thousands of users. That number is orders of magnitude less than the number of liquidity providers a top AMM may reasonably expect.

The naive approach had no chance of working, which makes the existence of liquidity farms so much more impressive. At some point, someone ran with the idea and came up with an optimization that opened up the ‘staking era’ of DeFi. The main insight needed for reward distribution is to realize that payout transactions are, for most blocks, the same - which allows a contract to group them together.

Let’s take an example. Alice and Bob are the only two users to stake their tokens in a farm (one LP token each). Thus, they each earn the same share of rewards. If the reward rate is 9 REW (reward tokens) per second, Alice and Bob will each get 4.5 REW per second. To avoid making a transaction every block, a contract can just keep track of each participant’s earning rate and calculate how much REW they’re owed when they request a payout or unstake their tokens. More specifically, if Alice requests her rewards 100 seconds after she staked her LP token, and she is supposed to receive 4.5 REW per second, the contract would just send her 100 * 4.5= 450 REW in a single transaction. Simple, yet powerful math!

What happens if Bob deposits another LP token? The farm would now have, in total, 3 LP tokens staked, one from Alice and two from Bob. Given the same total distribution rate of 9 REW per second, Alice should earn 3 REW per second, and Bob would get 6 REW per second. Additionally, when the change happens, the contract could pay Alice and Bob for the last period (where they each got 4.5 tokens per second).

There is still a major way to improve the contract further. Note that, in the method above, when the reward weights are changed, we need to recompute the reward rate for every user. If you’re aiming for many entries, that recalculation is the main scalability bottleneck. Triggering payouts for everyone every time someone stakes or unstakes some tokens is also pretty inefficient.

The solution is to keep track of a reward accumulator. This is the REW one token of LP would earn if it was staked at the very beginning of the reward distributor. Let’s take another example. Say Bob staked an LP token when the accumulator was 200 (thanks to things that happened beforehand and are irrelevant) and the distribution rate was 1 REW per second. Bob is a pretty indecisive guy, so he unstakes his LP just 50 seconds later. Given the rate, the accumulator’s value is now 200 + 50 * 1 = 250 REW. Bob receives the difference between the current value of the accumulator and the value when he first staked his token: 250 - 200 = 50 REW tokens paid. If he staked 2 LP tokens, the amount would double.

This might seem like a step backward at first - we’ve gone up in complexity only to get the same result. However, this method is far better because we now only care about the accumulator, not direct reward rates to individual users. There can be thousands or millions of rate adjustments between a stake and unstake operation - user-specific data (namely, the number of LP tokens Bob staked and the value of the REW accumulator when Bob staked them) is only accessed when rewards need to be paid out. This decoupling also means the liquidity farm has a compact state that is modified frequently - cumulative reward per share (the accumulator) and total deposited shares (LP tokens), along with epoch information (e.g., how many rewards to distribute and until when). Bob’s actions will not lead to Alice’s or any other user’s particular data being updated, but rather only change the small state in a way that’s easy to compute.

If you’d prefer a more academic format, you can check out the paper that nicely presents the idea here.

What DIG is Doing

Last year, Michael Taylor reached out to me looking to build an on-chain solution for DIG mirror rewards. The system at the time involved the validators (reward managers) sending payouts at fixed intervals of time. Its main issue was throughput - the fewer payments per week, the more trust mirrors put into validators, as users are not certain they’ll receive rewards until they see them in their wallet. However, more frequent payments would bring more network activity, which means more fees paid for distribution. If you’ve made it to this part of the post, you probably have a good idea of what a good solution to the problem looks like.

With the design presented above, the ideal (trust-minimizing) number of payments goes from “once every second” to “one when a user requests it or the mirror goes offline” - no matter what happens, mirrors get paid for the time when they have active shares in the rewards distributor.

Minimizing the number of on-chain payments is a goal in itself, but putting all active mirrors into a singleton lets us remove even more trust. For example, DIG rewards don’t necessarily need to come from the validator - anyone can add them to the current reward period or commit them to a future epoch. What’s more, if the validator misbehaves, sponsors (people who contributed rewards to future epochs) can claw back a percentage of the rewards, disincentivizing bad behavior. This opens the gates to a decentralized content network, where people interested in making some data accessible can contribute to the reward pot that gets distributed to mirrors that store and serve the data.

More recently, Michael asked me how hard it would be to turn the reward distributor into an NFT farm. Essentially, the code that allowed a trusted validator to add/remove entries was replaced by code that accepted any NFT minted by a particular DID for one share of the rewards. This makes NFT distributors an exciting way to reward NFT collection holders. The NFT reward distributor is now included in the official CHIP, which was just published for public review.

In a way, DIG - much like liquidity farms that came before - needed a very specific scaling solution. By optimizing based on transaction patterns, reward recipients can get the same assurance as they would get from payout transactions every second, all while not clogging the Chia blockchain. Reward distributors scale extremely well, making DIG prepared for its upcoming testing deployments, mainnet release, and eventual world domination. My hope is that, with this post, you’ve seen some of the magic that makes them possible.

The Cantina competition took place after the CircuitDAO codebase went through an audit from Zellic and an Immunefy private competition. For one month, anyone could analyze CircuitDAO’s Chialisp puzzles on Cantina and file vulnerability reports. The prize pot was distributed according to the severity of confirmed reports (valid vulnerabilities), as well as a report’s number of duplicates (the more people find the same bug, the less weight it has in distribution, incentivizing unique findings). For more information about competitions - which nicely complement security audits - check out this section of the Cantina docs.

Even though I joined toward the competition’s end, I found 3 critical bugs and 2 medium vulnerabilities, ranking 1st across all participants. I curated the list below not only because the findings are interesting, but also because they show things Chialisp programmers should be careful about when designing and writing puzzles. I was the only one to report the vulnerabilities below. This article is not intended to raise any doubts about CircuitDAO (see the end of this post for more about this). I’m publishing these findings with the permission of the CircuitDAO team. Without further ado (or disclaimers), let’s dive right in!

Finding One: Liquidating Everyone

As previously mentioned, CircuitDAO has a simple yet efficient mechanism to keep all loans overcollaterized: when the value of the collateral goes below a percentage of the value borrowed (e.g., 200%), a liquidation process is started. But, to value an XCH deposit in terms of BYC (1 BYC = 1 USD), the CircuitDAO protocol needs a trusted, on-chain XCH-USD price feed - where do they get that from?

The answer is the protocol oracle, which consumes multiple price feeds, calculates the current XCH price, and then announces it on-chain. Feeds are approved by governance and represented on-chain by announcers.

Each announcer is a custom singleton that multiple stakeholders can call. Its owner can, for example, update the announcer’s custody puzzle hash or add a price. Meanwhile, keepers - entities keeping the CircuitDAO protocol working while pocketing some profit - can slash the capital locked in the announcer if the price is stale (was not updated for a while). They can also make the singleton announce the most recent price along with the announcer’s approval status, allowing the oracle to access it. Governance is the only entity that can set an announcer’s `APPROVED` parameter to 1 (true), allowing it to send data to the price oracle. Anyone can create and operate an unapproved announcer, but only approved announcers contribute to the price feed used by the CircuitDAO protocol.

My internal alarm bells went off when I noticed that anyone can exit an unapproved announcer (i.e., not only the announcer’s owner). The functionality was originally intended as a way for announcer owners to recover the funds they provide as a guarantee for their announcers (which can be slashed when the announcer is active). Due to a missing permission check, however, anyone can make an announcer exit into its owner puzzle (i.e., create a coin with a puzzle hash of `INNER_PUZZLE_HASH`) through this path as long as the announcer is not approved by governance (`APPROVED=0`). By itself, this finding has low severity at best, as the worst someone can do is exit announcers pending approvals in some cases. What makes this finding much more severe is that it breaks lineage. At a high level, an announcer custom singletons coin checks it is valid through the following checks:

• My top (outer) layer is an announcer custom singleton with my state

• My parent is either the launcher or another announcer custom singleton

By requiring the parent to also be an announcer, the protocol ensures there are no invalid state transitions. For example, no one can just create an approved announcer, as the launcher asserts `APPROVED=0` and further spends only set `APPROVED=1` if governance passes a bill that says so.

However, through the exit path, an announcer coin produces a child with an arbitrary puzzle that automatically satisfies the second condition! This is only possible because the inner puzzle only runs when the owner of the announcer runs a puzzle - if a keeper uses the previous bug to initiate the exit and create the new coin, the inner puzzle doesn’t get executed at all. If the proper permission check was in place, an additional constraint was placed on the inner puzzle (i.e., that it had to run inside an unapproved announcer), which would invalidate this attack path.

That leads us to our attack. An attacker creates an unapproved announcer - an action that anyone can do. In subsequent coin spends, they act as the owner to update the inner puzzle hash to one corresponding to the hash of an announcer outer layer with `APPROVED=1`, then act as a keeper to ‘exit’ the current announcer top layer without revealing/executing the inner puzzle. Even though the parent performed an exit operation, the child’s puzzle hash will correspond to an announcer outer layer, which satisfies the first condition above. The second condition (parent is announcer) is also satisfied, meaning the attacker just turned an unapproved announcer into an approved one without involving governance at all. Ouch!

Given the last sentence, proving severity isn’t hard. If an attacker can create one approved announcer out of nothing, they can create a majority of announcers. Using those, the attacker would be able to fully control the XCH-USD price feed. By setting the price of XCH to, say, 0.001 USD, all loans would become undercollateralized, triggering mass liquidations.

In general, Chialisp developers should be careful when it comes to state transitions. While formal verification - a type of audit that translates code and assumptions to logical proofs and shows those are consistent and valid - is ideal, just thinking about how an attacker can lead a coin to a state it shouldn’t be able to achieve can sometimes uncover critical vulnerabilities.

Finding Two: Bricking Auctions

The CircuitDAO protocol has a treasury, which is the place where loan interest payments (stability fees) go, and also the source of BYC paid as interest for locking up BYC in savings vaults. When the treasury has too much BYC, a surplus auction can be started, where people bid CRT (governance tokens, which will be burned) to buy the excess BYC. When the treasury balance dips below the minimum set by governance, recharge auctions start, where people bid to sell BYC and get freshly minted CRT in return.

Both auctions work over the span of multiple blocks. Bids are accepted from anyone as long as the amount is higher than the last bid, in which case the last bid is refunded. An auction ends when the current bid hasn’t been outbid for a certain amount of time (3 days, for example).

The bug that breaks the auction mechanism is a seemingly innocent lack of validation. When a user bids, they supply a puzzle hash (an address) where funds should be sent (either the bid refund or the auctioned asset). This parameter is kept in the auction’s state and used in a subsequent spend. It is not, however, sanitized at all. That seems fine at first - even though a puzzle hash is 32 bytes long, providing a value that’s another length (33 bytes long, for example) is not a problem, as the CAT layer will wrap whatever bytes are provided and generate an output hash. The new coin would be unspendable, but this would just be the equivalent of providing a wrong puzzle hash to the auction - which is user error, not a vulnerability.

The trick to break the auction is to provide a list as the puzzle hash. Whether you win the auction or get a refund (because you were outbid), a CREATE_COIN condition with a puzzle hash that’s a list instead of bytes will be emitted. When the CAT layer tries to wrap the list in a CAT outer puzzle, it will raise an error, making the whole bundle invalid. But that is not the bid bundle - instead, it’s the next user’s, who’s trying to outbid you or settle the auction. What’s worse, you can bid any amount - so, if you get lucky, you may be able to place a malicious .001 CRT bid on a 100.000 BYC auction and brick it forever. Surplus auctions store the BYC in a payout coin that would become unspendable after such an attack, meaning that the excess BYC would be lost forever.

Generally, always make sure to check all user input - the spend should fail if a wrong value (or a wrong type) is passed. This is especially important since Chialisp is not a typed language. As the vulnerability above shows, a failure in subsequent spends might be the reason there is an issue in the first place.

Finding Three: Stealing Bids

While writing a report for the last vulnerability, I also realized that the target puzzle hash is only used to set/update the last bid state. That means it didn’t appear in any other place in the code - so bidders had no way to assert the value is set correctly, as the solution of a bid coin is not signed, and no announcements contain the target puzzle hash. A malicious farmer could simply parse the original bundle and replace the included puzzle hash with theirs - that way, if someone outbid the current user, the funds would be sent to the farmer. And, if the user won the auction, the farmer would get the pot. Essentially, a user pays for the bid, but the farmer gets all the rewards.

This is bad on paper, but it’d take a lot of effort to set up a significant number of malicious farmers in practice due to Chia’s decentralization. There is, however, a trick to make this a critical vulnerability - enter Replace-by-Fee, a mechanism used by the bridge when another operation is already pending, TibetSwap when someone else is interacting with the same pair, the Dexie ‘bump fee’ feature, and probably most apps in the future. Pending spend bundles cannot just be replaced since that would open the mempool to several attacks. However, you can replace mempool items with new ones if the new bundle meets a few constraints:

• All coins in the original bundle are still spent (superset rule)

• The fee-per-cost of the bundle increases (more specific rules are irrelevant)

This opens up another possibility for the attack, where a malicious actor can steal all bids by simply watching the mempool. Whenever a spend bundle is detected, the attacker can take the original bundle, change the target puzzle hash, attach a higher fee, and send the new mempool item to the network. The old mempool item will be replaced by the ‘malicious’ one through Replace-by-Fee, as both the superset and fee increase constraints have been satisfied. The user paid to make a bid, but the attacker gets all the proceeds (refund or won lot).

In general, dApps should always provide a way for users to assert that they’re doing what they want to do. This can be more lax than just announcing all input parameters - offers, for example, allow you to assert that assets are sent to a puzzle hash without enforcing which coins need to be used, and their flexibility is what gives them power. The proposed security measure often comes in the form of extra output conditions, which will consume additional cost (‘make transactions bigger’) - but the alternative, as you can see above, is not a secure option. While Cantina’s rules would consider this bug family to be one vulnerability only, the attack above led to CitcuitDAO revising multiple areas of the code.

Should Security Be a Concern?

Security should always be a concern. On blockchains, the problem of security is even worse, as money locked in a protocol usually incentivizes hackers to exploit rather than report security issues. As a user, the real question is whether the probability of a hack is low enough to justify putting money in the protocol. In other words, yield is never risk-free, but users can weigh it against the protocol’s perceived risk.

Having said this, we should applaud the CircuitDAO team. Organizing and going through multiple audits/competitions is a time and capital-intensive process, even if you’re not using a lesser-known language such as Chialisp. Still, they’ve been audited by Zellic (one of my favorite top audit firms), held a private Immunefy competition, and just wrapped up a huge open competition on Cantina (where I participated for a week and reported the bugs above - and a few others). They’ll also soon launch a public bug bounty program a Cantina - if you know how to read Chialisp and would like a challenge, I highly encourage you to check it out!

Each bug reported before mainnet means a fix can be applied before the protocol goes into production. Users and community members should create strong incentives for protocols to go through thorough testing before launching instead of just “winging it” and needlessly putting funds at risk. While the instinctual reaction to hearing that critical bugs were uncovered is to be concerned, remember some protocols just choose to not perform any kind of security assessment. CircuitDAO, a very complex protocol with many moving parts, is undoubtedly on the right path to mainnet - the one with many security reviews.

So, as an end user, how do you know if the yield justifies the risk? I personally (not legal or any other kind of advice!) look for two things in highly secure protocols:

• Multiple audits from reputable firms, with published reports

• Few severe bugs in recent audit(s)/competition(s)

Security assessments can never guarantee there is no bug left - but I think the indicators above make it unlikely that the protocol has unresolved severe vulnerabilities.

Given the nature of this article, it’s fitting to end it the way I wrapped up posts on my old cybersecurity blog:

Until next time, hack the world.

yakuhito, over.

In the previous blog posts, I explained the problem of uniqueness, as well as a great nice solution for it. This post’s main theme is: now that such a primitive exists, what dApps does the ecosystem need the most? Without further ado, let’s jump right in.

The needs

The first obvious need is names. I want to tell people to send me money at ‘yakuhito’ instead of an XCH address. I have tremendous respect for the services that have attempted to do that, some of which have also used the proceeds to support the ecosystem. That said, a decentralized option is better - it gives users confidence that the names will be available in 10 years and the service will continue to follow the same rules. After a lot of thinking, I have decided to name this service XCHandles.

Side-note: While it’s harder to build and launch, the maintenance of XCHandles is actually easier - there’s no registration key you have to be careful not to leak. Even if the main API/website goes down, wallets can have code that still allows them to resolve names and register them on-chain. XCHandles only goes down when Chia goes down. Worst-case scenario is that you lose control of the address where registration fees go - in which case, the name service continues to live on without any issue.

The second one - also suggested by Ken - is a CAT registry. If you’re a Chia user, you probably aren’t aware of any problems with CATs. But issuers and owners of sites displaying CATs have been battling with it for a long time. In essence, there is no ‘one place’/source of truth where you can go and put the details of your CATs so other sites - like Dexie or TibetSwap - pull them. A decentralized CAT registry - which I will refer to as CATalog from now on - is the best solution, as CAT issuers can own their entries and update them whenever they see fit.

There’s, of course, more to both XCHandles and CATalog than this. Let’s dive in!

Designing XCHandles

I like to think about XCHandles as a decentralized address book - but, in reality, it was designed taking a lot of inspiration from DNS. The Domain Name System (DNS, for short) is the collection of systems responsible for offering and managing domains - such as fireacademy[.]io. The reason XCHandles should be similar to them is that they’re fundamentally offering the same things: names that resolve to dynamic things (be it IP addresses or wallet addresses) and can be registered by anyone (add ‘mostly’ to the last part when talking about DNS).

The first major design decision was to let XCHandles expire. To understand why, let me take the example of my twitter handle - which is ‘yakuh1t0,’ not ‘yakuhito.’ In 2013 - years before I joined Twitter - someone registered as 'yakuhito’ and then left the site - no follows, posts or any activity since then. I would argue that the ‘yakuhito’ handle should come with a mechanism that ensures it’s being used - and the best way to get to that is to make people pay for the time they own handles. At a higher level, if you leave Chia for good or lose access to your handle, there should be a mechanism that eventually allows someone that really wants the handle to get it without having to get in touch with you. This is also, to a certain extent, a great way to prevent ‘squatters’ - people who would register a lot of handles only to offer them at much better prices when someone wants one - since they would have to pay to maintain their collection of handles. DNS has been doing this successfully since around 1983.

The other design decision was to make some handles more expensive. There’s a lot of factors that make some domains more valuable than others - the one I put into XCHandles is based on name length. A 3-letter handle (e.g., ‘yak’) will be more expensive than an 8-letter one (e.g., ‘yakuhito’) since less 3-letter handles are available overall. Since XCHandles are tradeable, a secondary market for handles with other properties (e.g., keywords) will probably establish itself.

That’s pretty much it - in all other major ways, XCHandles will work like most name services on other blockchains. Names are represented as NFTs that the users control - and are free to update and trade as they see fit.

Designing CATalog

CATalog is very interesting in a lot of ways. But, first, let’s talk about how you can build a decentralized CAT registry.

In essence, the goal is to have CAT issuers (‘owners’) control entries in a decentralized registry. This brings up the question: how do you check if someone is the issuer of a new CAT in a decentralized way? We have to keep in mind that CATs can have all kinds of issuance rules - from single issuance, where the owner is obvious, to liquidity CATs on TibetSwap, where the ‘owner’ is not necessarily the user that the funds came from.

The solution is to consider knowledge/information asymmetry. An issuer is a person who came up with the CAT - they’re the first ones to know about the CAT. CATalog can award the CAT entry to the first person that committed the CAT’s asset id on-chain (in most cases, before the CAT was actually issued).

This means that CATalog ensures the uniqueness of TAIL hashes to prevent double-registration - not CAT tickers. The problem with CAT details other than the asset id is that a Chialisp program can’t verify that their values - such as tickers, names, and images - are not misleading. Moreover, sites using CATs would want some vetting power over the CATs they display anyway. Site owners should be able to decide whether the CAT is appropriate for the site or not.

To fix this issue, we must see the registry as ‘PVP-enabled’ - scam attempts are a given. The singleton’s sole purpose is to give CAT creators the power to update the entries for their CATs on-chain - it’s a decentralized CAT database with no regards for the content of the entries. Content ‘filtering’ comes from a layer on top: site owners create on-chain verifications from their DIDs to actively flag CATs as not being misleading. These verifications can include other data (such as the CAT’s specific category on the site). Verifications can also be revoked at any point.

With this new ‘layer,’ CATalog becomes a collection of on-chain resources describing CATs. Issuers register entries and update values. Site owners - and any other DIDs - then create verifications for the values, saying that the content is ok from their perspective. Some dApps might choose to trust someone else - such as Dexie or SpaceScan - to curate CATs for them. This is, in my opinion, the best solution for a token registry that I’ve seen or thought about.

Lastly, CAT registrations last forever. A CAT owner can disappear while the CAT itself is still valid - if that is no longer the case, verifications can be revoked so CATs are no longer listed on websites that wish to hide them.

Wrapping up

If you’ve ever thought that launching a dApp is hard, try launching two! Jokes aside, while XCHandles and CATalog would be easy to launch on an EVM blockchain, a lot of work is needed to get them up and running on Chia.

Along with this post, I’ve also made this repository public. It contains Chialisp code that powers these new dApps, along with draft driver code and working tests. This series didn’t talk about a lot of other stuff - from a new, specialized layer for dApps to the drivers being implemented in Rust instead of Python. A bit more testing under real-world conditions is needed before I’m comfortable with releasing CHIPs and a plan for mainnet. Stay tuned for more news - coming next year!

Special thanks to stl and (or, maybe, a.k.a. 😉 ) Bob for reviewing this article.

In the previous blog post, I presented the problem of uniqueness. As a short recap: there’s no way for singletons to check that a value (e.g., a name) hasn’t been used (e.g., registered) before. In this post, I’ll explain a previously proposed solution - and why it doesn’t work - as well as a solution that does work.

But first, back to the basics: let’s talk about hashing.

Hashing 101

There are many ways to describe hashing - but let me invent a new one based on AI’s rising popularity. Let’s imagine we have a robot that labels things - you give it an object, and it puts a label on it. Let’s also imagine that it’s 2100 - so the robot is powered by a combination of GPT-313, Gemini-7, and Grok-42. At this point, no one has any idea what the labels mean - but they’ve observed the robot puts the same labels for identical objects (i.e., two apples will have the same label). The robot also never uses the same labels for different objects (apples and pears will have different labels).

Hashing is just the digital equivalent of the Labeler 3000 robot:

Hashing algorithms (yes, there’s more than one - although SHA256 is arguably the most popular) take a piece of data (of any size!) and output a fixed-size ‘fingerprint’ of that data. They have two properties that make them special:

• Deterministic: Given a piece of data, its hash is the same no matter the time or computer I run the hashing algorithm on. In other words, getting the same input through the same algorithm should produce the same output. Intuitively, it makes sense for a fingerprint to remain the same for a given object.

• Not Reversible: Given an output - a hash value - it’s really hard to determine an input string that produces that output. More specifically, if I give you the hash ‘e378e72a75855c08d49b6421b04374a1c16d36f4f1cec3d06a3da38053a8fdcd,’ your best bet to determine what value produces it is to go through many values, hash them, and see if the outputs match (that string is the SHA256 of ‘yak’ - not that it matters).

The latter property leads to the comparison between hashing and a blender being frequently used. Blended apples would look the same (and differently from a blended oranges) - but good luck reversing the blender’s effect on the apple. Algorithms such as SHA256 have been carefully built to act like a digital blender. They take data in batches, and mix it into the output value in a very complicated way.

Now that we got that out of the way, let’s talk about one very cool use of hashing!

Merkle Trees

For every spend, the TibetSwap singleton has to run one of the following puzzles: add liquidity, remove liquidity, swap XCH to CATs, swap CATs to XCH. The goal is to make this mechanism take as little space as possible on-chain in order to minimize transaction cost.

The first place where hashing can be used is to ‘compress’ puzzles. Instead of storing the whole puzzle, we can store a hash (a ‘unique fingerprint’) of each puzzle in a list. When the singleton is spent, a full puzzle is given - we can hash that and see if the fingerprint is in the list of hashes that are allowed to run. It’s like implementing perfect biometric security for access into a building - if you have the wrong fingerprint, you’re not getting in.

However, we can do even better. Merkle Trees let us ‘compress’ the whole list via hashing. Here’s how this would be done for a list with 8 items:

The method to build a Merkle Tree is simple: you take every 2 items from the list and hash them together. That gets you from the bottom level (1, 2, …) to the second level (12, 34, 56, and 78). You can repeat this procedure until you only have one hash left - 12345678 in the image above. This ‘top’ hash is usually called the Merkle root. You have now stored the data in a very clever way: when you want to prove that an item is part of the original list, you only have to provide a few intermediary hashes, like below:

Let’s say you want to prove 3 is in the original list. By providing 4, 12, and 5678, someone can get at the Merkle root (top hash) from ‘3’ - all without knowing or using the whole list! The really elegant thing here is that nodes 1,2,5,6,7,8 are not included in the proof - instead, intermediary values such as 12 and 5678 ‘cover’ more than one node.

Let’s compare this to the ‘naive’ solution of hashing the list and accepting a reveal. In that case, you would have to provide all 8 hash values (1-8) to check if a puzzle is allowed to run. With Merkle Trees, you provide the puzzle hash (3) and 2 intermediary values (12, 5678) to compare against the Merkle Root. More generally, with Merkle Trees, you’re looking at log2(n) items instead of n for proofs of inclusion - which makes them a really great tool!

Previously Proposed Solution

We’re now in a good place to understand the best solution proposed for the problem of uniqueness so far. Back in 2023, Ken (also known as fizpawiz - a great Chialisp developer) published “Decentralized Names on the Chia Public Blockchain”. He suggested that we can use a Merkle Tree of sorted values to prove a name hasn’t been registered before - like the one below:

The idea is very elegant: to prove that 7 hasn’t been registered, prove that 5 and 10 have been registered, and that they’re next to each other in the current Merkle Tree. Because the list is sorted, you know for certain that 7 hasn’t been registered.

This idea has apparently also been proposed as a solution for the name service of Cardano. Unfortunately, it won’t work - while they’re good for proofs-of-inclusion, Merkle Trees are not practical for proofs-of-exclusion.

Let’s first assume we want to keep the new item - 7 - on the same ‘level’ of the tree. After the name is registered, the dApp will have to calculate the Merkle root of the new tree (i.e., one where 7 is part of the list) so future registrations can be processed as well. What intermediary hashes will have to be recomputed after 7 is inserted?

The answer is: most of them. When you’re inserting 7, you’re shifting the nodes on its right by one. Because you always hash nodes in pairs, all pairs on the right will change, and a lot of rehashing will need to be done. In practice, you end up having to reveal a majority of the initial list in many cases. That’s not practical because of size constraints - the more data your transaction contains, the more expensive it is. Additionally, blocks have a limited maximum size - at some point, you won’t be able to register some values because the data that needs to be revealed to register them doesn’t fit in a block.

There is, of course, another alternative to insert 7 - the one which Ken thought of when proposing the solution. What if, instead of keeping everything on the same level, we create a new one? When we insert 7, we can just turn the ‘5’ node into ‘5,7’. This sounds much better, as you only have to recompute log2(n) nodes, and you no longer have to reveal most of the tree.

Indeed, the problem in that scenario is smaller - but it’s still there. If your tree grows differently in different locations, it will become unbalanced. Assume someone also registers 5.1, 5.2, 5.3, 5.4, and so on. When I want to register 6, I’ll have to reveal all those values, plus 5 and 7. The 6 item would be added to a very ‘long’ root in an otherwise pretty shallow tree. This ruins the nice property of Merkle Trees that we’ve talked about - proofs are no longer log2(n). Moreover, this is a shared application - so someone could in theory ‘attack’ the dApp by registering 5.1, 5.2, etc. in order to annoy the person who’ll want to register 6.

There are, of course, other types of trees as well. Specifically, B-trees, which were created for databases, are very good at ‘auto-balancing’ the tree so insertions/deletions are still done in logarithmic time. But they also reveal another weakness: as we add more fixes on top of the tree idea, the code is getting more and more complex. That increases transaction cost, development time, and attack surface - isn’t there a much simpler alternative?

Trees are not the solution

I have myself been stuck down the rabbit hole of trees for a very long time - that’s why I know what a B-tree is in the first place. However, it’s important to keep in mind there are other data structures that could be used in our battle against the problem of uniqueness. So let’s go back to the basics.

We want something that ensures an item is unique - and we’ve seen that sorted lists are great because they allow us to prove uniqueness by looking at two neighboring items only (recall that, if we see 5 next to 10 in an ordered list, we can say for certain 7 hasn’t been registered before). However, we also want to insert new items into the list as easily as possible (ideally, O(1)). Allow me to introduce the data structure that can solve the problem of uniqueness: sorted, doubly-linked lists:

Doubly-linked lists are a known programming data structure with a simple idea: each node (item) also knows - aside from its own value - its neighbors. So, for example, node 5 will also contain the information that its left neighbor is 1 and its neighbor on the right is 10. What’s really cool is that, when you want to insert 7, you only have two update two nodes, which will be his future neighbors: 5 and 10. Specifically, you’ll ‘break’ the link between 5 and 10 by setting 5’s right neighbor to 7 and 10’s left neighbor to 7. Moreover, if you check 5 < 7 < 10, you can verify 7 hasn’t been registered before at the same time!

This is nice and would be a great way to solve the problem of uniqueness - if we properly store the list on-chain. Recall that each node contains 3 values (its own value + its two neighbors), and that we don’t want to have to reveal the whole list every spend. Let me give you a graphical hint on how we can do it:

The essential idea that makes it all work is to have each element be a coin. The registry singleton only interacts with node coins when they’re used - i.e., when they’re the future neighbor of a value being inserted. The user/wallet provides the relevant coins when registering - remember, just looking at two nodes is enough to make sure the value hasn’t been registered before. And that’s how you (simply) solve the problem of uniqueness.

One last thing to note is just how much sense this solution makes. After you register a value - say 20 - you only need to access it when one of its neighbors will change (i.e., to prove a value next to it hasn’t been registered before - and insert it). When it’s not needed, however, the coin containing 20 will remain unspent - which doesn’t increase the cost of a transaction on the underlying registry singleton at all. In other words, proving a value is not part of a list of 100 items is the same as proving uniqueness in a list of 1,000,000 items - which solves a huge concern of dApp developers (“will it scale?” - yes, this part of the dApp will).

Up next

When I presented this solution to other people (I had to make sure I wasn’t crazy), their initial reaction was “Wow! That’s clever!,” followed by “It’s so much simpler than I expected.” In my book, the simpler you can make a dApp, the better.

I started calling the coins that store the list items “slots”. I think slots will have much broader functionality beyond what I initially used them for, as singletons can essentially ‘save data for later.’ For example, slots would give a liquidity farm the ability to not only store the amount of liquidity tokens you added to the farm, but also the cumulative rewards at the time of deposit - making liquidity farms finally possible on Chia. Slots can do that without using a doubly-linked list structure - in a way, they become ‘tickets’ that liquidity depositors can later redeem for their tokens and accrued rewards.

Taking a step back, I do think this concept has lifted the final barrier to more advanced Chia dApps. I’m really excited for what’s next - so join me in Part 3 to see the PoCs I built to test out this new primitive’s capabilities.

Special thanks to stl and (or, maybe, a.k.a. 😉 ) Bob for reviewing this article.

Chia is very different from account-based blockchains like Ethereum. The ‘fundamental’ unit on Chia is a coin - which has a parent (i.e., source that created it), an amount of mojos, and a puzzle - which contains the ‘rules’ that control the value locked in the coin. This change from “there are smart accounts and a JavaScript-like language is used to control them” means that a lot of basic stuff is wildly different from Ethereum or other cryptocurrencies.

There have been two major breakthroughs that allow dApps today to exist on Chia. First, singletons allowed a lineage of coins to maintain an ‘identity’ through spends. A coin can only be spent once - but the singleton primitive allows one of the coin’s children to be marked as a ‘successor.’ This makes it possible for NFTs to exist - the unspent (latest) coin holding the NFT itself changes each time you do a transfer, trade, or metadata update. But the underlying NFT id and state (metadata) are preserved through spends.

Second, the launch of TibetSwap provided a ‘sketch’ for simple dApps. Besides showing the community that dApps were possible on Chia (many community members thought they weren’t), TibetSwap had a ‘structure’ that showed one way of:

• Holding state variables that change frequently inside a singleton (e.g., the amount of XCH locked in a pair, which changes with each trade)

• Emulating Solidity’s function selectors, which allow different ways to interact with accounts based on what you want to do. For example, when you add liquidity to a TibetSwap pair, some of the code that runs is different than the code that runs when you do a XCH → CAT swap.

Even with the two advancements, a small issue still prevented complex dApps from being built on-chain. I call it the problem of uniqueness, and this post is intended to explain it.

Why don’t we have a fully decentralized name service on Chia?

The easiest way to demonstrate the issue is to show a place where it heavily influenced how solutions were designed: name services.

As most crypto users know, a name service is mainly responsible for translating a human-readable string - such as ‘yakuhito’ - to a blockchain address. It’s a decentralized address book. Currently, there are multiple such services on Chia - from the Chia Name Service and NamesDAO, which offer on-chain name NFTs, to sites such as go4me and MyXCH.space. However, unlike their Ethereum counterparts, they are not fully decentralized - someone’s key is used to create your ‘domain’, and that someone can also register the same name twice or refuse your registration request. The question is: why is there a ‘private key’ in the image below?

No one wants the responsibility of being an admin - it adds complexity and a lot of responsibility to a system that should be unstoppable, uncensorable, and available 24/7. Teams like CNS have very deep knowledge of the Chia blockchain - so why settle for something less than ideal?

The core issue is that, while singletons allow you to hold some values that change over time, they come with limitations. Too many values will make your transactions more expensive - less can fit in a block, and users will have to pay more fees. Moreover, there’s no ‘direct’ way of proving something is unique (a list of registered names would get too big after just ‘a few’ registrations). Combined, these issues mean that a registry singleton has no way of checking whether ‘yakuhito’ is an active name when someone makes a request to register it.

A lot of people have been thinking - directly or indirectly - about a solution for more than two years now. I call this the problem of uniqueness - and it shows up almost every time you want to design a complex dApp.

Side-note: Those that know a bit of Solidity will notice that the problem is trivial to solve on Ethereum - just use a ‘mapping’ structure! That’s not available on Chia.

Where does the problem show up?

Aside from name services, there are several apps where the problem shows up. Each time, the solution is highly specific and present several drawbacks.

NFT

NFTs - actually, singletons - were the first puzzles to face this issue. The way you ensure only one unspent coin exists at a time is by having an id - when a coin is spent, it passes that id to one of its children (or, in special cases, it doesn’t - a process that destroys the singleton which we call ‘melting’). The clever solution the creators of the puzzle came up with is to use the first singleton parent’s id as the singleton id. In other words, singletons distinguish themselves by the coin id of the ‘creator’ coin - which is usually called the singleton launcher. This is a great idea because it uses a consensus rule - the one saying that all coins must have a unique id - to give singletons their ids. The major drawback of this design is that it relies on coin ids - which depend on parent ids, making it impossible to use the same system to store custom values. Think of it this way: you can prove uniqueness, but the entries of the list are all random 32-byte values - not ‘yakuhito’ or other names.

TibetSwap

In TibetSwap, a singleton called the ‘router’ launches new pairs. One of its main purposes is to allow people to ‘index’ pools, which are always XCH-CAT and currently only have one fee tier. Ideally, the router would assert a pair for the same assets has not been created before when deploying it - which would allow other dApps to do a lot of cool things. However, as stated above, that wasn’t quite possible when TibetSwap launched - so the second best alternative is to have the router launch pairs for any assets and then make the driver code only mark the first pair valid. This mechanism is off-chain - you can’t prove it on-chain.

warp.green

The bridge had a similar issue - given the id of a message, the singleton would ideally be able to assert that it hasn’t been relayed before. Because, if you bridge 40 USDC to Chia, you should not be allowed to claim it twice under any circumstances. The solution I came up with is to embed the previously bridged message ids in the singleton’s puzzle. When validators sign a message, they also sign the id of the [singleton] coin that can relay that message - which depends on the ids of the messages that were relayed last spend. The id also depends on the parent’s id, which in turn depends on the messages that were relayed two spends ago. Essentially, a ‘message id chain’ is created with each coin id containing the messages that were relayed previously (in a recursive manner). There are two limitations with this approach:

• Validators need to sync the relayer singleton’s full history to assert that a message hasn’t been relayed before - and actually perform the check before signing a message

• This approach needs a centralized party that does this indexing off-chain. In this case, bridge validators were already there for other reasons - but a lot of dApps will probably not want to insert a centralized component just for uniqueness checks

Up Next

I hope you enjoyed this primer on the problem of uniqueness. As a recap, the problem is that puzzles (or rather, singletons) can’t check that a certain value hasn’t been used before for something. In the next post, I’m going to walk you through the most promising solution that has been put forward - and why it doesn’t work that well. With that said, join me for Part 2.

Special thanks to stl and (or, maybe, a.k.a. 😉 ) Bob for reviewing this article.

Chia community members have been asking for Ledger support for quite some time. That being said, making a Ledger app is not easy. From what I’ve heard, the coding part is difficult just by itself. There’s limited space - Ledger Nano X has 2 MB of storage, which is advertised as being sufficient for ‘up to 100 apps’ - and very limited computing power. Within these constraints, building an application that can parse Chia transactions might not even be possible - and we haven’t even considered issues such as application verification requirements, limited screen size, and possible delays in getting support for new primitives.

If developing a Ledger app is so difficult, why not find an alternative path? To understand how that’s possible, we first need to take a step back and talk about a popular Ethereum standard.

EIP-712

When people say “signing” in crypto, they usually refer to signing transactions. But the cryptographic primitives powering blockchains mostly allow signing *any* data. At some point, some websites/dApps started asking users to sign messages off-chain - the signatures would either be used for logins (i.e., proving the user owns an address) or later submitted on-chain to custom contracts.

There was, however, one big problem: users didn’t know what they were signing. They only saw a final hash - with no way to tell if they were signing into a website or approving a malicious actor to drain all their funds on another dApp. The signing requests looked like this:

The EIP-712 standard was proposed to solve this problem by specifying a way to convert structured data into a hash to sign. Websites could then pass the structured data to wallets, which parse it and display a much nicer request to the user:

Most wallets currently support the EIP-712 standard (including hardware ones), which made it an interesting avenue to explore. A Chia wallet could just prompt users to sign a message to ‘prove’ they want to spend a coin in a specific way. Indeed, the demo puzzle I used last Friday verifies the signature of such a message on-chain. Here’s how the signing request looked like in my Tangem app:

The puzzle was made to act as a replacement for the standard puzzle - meaning that hardware wallets should be able to hold CATs, NFTs, DIDs, and any other primitives we invent. Because EIP-712 is so widely supported, this approach allows integrating Chia with pretty much all wallets that support Ethereum and EIP-712.

CHIPs

There was one critical barrier in adopting EIP-712 for Chia: Ethereum uses keccak256 for hashing EIP-712 data, while Chia relies on sha256. The keccak256 operator isn’t currently available in chialisp.

Thankfully, there is a process through wich new operators can be added: CHia Improvement Proposals (CHIPs). Community members can propose standards or operational changes, which undergo a feedback phase. Some proposals end up being withdrawn (such as the one proposing a minimum transaction fee), while others pass (such as the one defining an upgrade to the datalayer standard).

After my request, the keccak256 operator now has an associated CHIP that will eventually add it to chialisp.

What’s Next

Now that we have a clear use case, the keccak256 CHIP will proceed at full speed. Since it’s a new operator, a ‘soft fork’ will be needed, meaning nodes will need to be updated to support keccak256. In practice, this involves a transition period - typically 2-3 months - before the operator is enabled, giving farmers and other node operators time to upgrade their software.

While the CHIP process is in motion (follow it here), there’s more groundwork to lay for hardware wallet integration. Rigidity has been working hard on an impressive Chia SDK I’ve had the pleasure of using many times (including in this project), as well as a new wallet called Sage, which plans to support the new puzzle. This is a complex undertaking, so if you’d like to help, consider supporting Sage development, either by donating here or by spreading the word about Sage (available in beta here).

Special Thanks

• Julie for first suggesting using EIP-712 in this thread with me. The previous solution involved signing ‘fake’ Ethereum transactions and was much more convoluted.

• CNI for going through with my CHIP request even tho it wasn’t clear if the idea would work or how it would work (the latter being a communication problem on my side).

• Rigidity and Indigo for quickly getting keccak256 PRs set up, thus enabling the development environment I needed. Also for going through the softfork operator with me.

Subscribe now