ZK Proofs and TradeLayer
Oldtech goes back to the Future
Bitcoin and Litecoin are old. If they were human beings they would be tweens, being rude and over-using screens in their rooms, with Bitcoin just starting to get well-adjusted, becoming athletic, applying for business school scholarships and making new, and powerful friends. Meanwhile Litecoin has been the but of meme jokes for years, “what’s it for?” etc. etc. But there is a bright future for these technologies that will accomodate the very best of Ethereum’s R&D into an L2 and L3 future that will make you blush. Bitcoin, as with Ethereum per Vitalik Buterin’s vision, could become majorily populated with transactions from ZK Validum Proof Oracles, DAOs, of course centralized exchanges batching withdrawals still to some extent, and whales moving their stack whoelsale, an indulgently expensive necessity for those who haven’t wrapped their coins in LN channels or TradeLayer Repo or other avenues of flexibility. A future, where the fees are enough to sustain the geopolitical independence of the host nations that endorse mining, the “free world” as they used to say.
TradeLayer is here for it. We can put URI’s to a data availability platform such as Arweave into the OP_Return byte length, and those URI’s can contain much longer Validums. Personally, we like the idea of paying to carve those Validums into the Bitcoin blockchain itself, why? What were the arguments against big blocks back in 2017?
Quadratic computing time in verifying, 2MB takes ~4x as long, ad infinitum
Big Blocks will make running full nodes prohibitive faster
The political lack of fiber will lead to a Trotskyite perpetual revolution
The first problem has been solved, by consensus of the Bitcoin Core Devs, Twitter Maxis, and Silent Majority, plus the Miners, they technically flagged it in. We have Schnorr on Bitcoin, finally, patent expirations be praised. Linear computing of bigger blocks is possible.
The second problem will be solved very soon by ZK proofing of Bitcoin logics to construct Validums of state for block N and all that preceeded it. One can avoid heavily refactoring RPCs by using typical LevelDB look-ups and operations that can sort through the recent 100s or 1000s of blocks in memory. A user will be able to specify how much of the history they want in a ZK, and how much they want 100% K about (e.g. by replaying it in memory, having the data available). Users will be able to look at their recent spending on their phone where 100 MB of blocks are kept, plus of course a memorialized “statement” of prior months, like how banks do that, and then have a Validum that encompasses the entire past of Bitcoin. Imagine that! 100 MB Bitcoin lite “full” nodes. A data-availability based traditional full node has a few privelidges, such as being able to participate in generating proofs.
The third problem may be fundamental and gives credence to the whole Maximalism position, not because it is correct, but because it is counter-revolutionary and these dang revolutionaries destroy the social expectation of consistency in the tenets of their asset. I have seen the BCH community destroyed, driven reckless by madness, ego, poker fortunes turned to scurillous galavanting Chain Wars that sputtering like violent e-waste onto the streets of Twitter, splurging volatility into an unexpected spillover that ruptured like the Erfurt latrines, drowing its torrid nobility in a grave of ignominous negative PNLs, which ruptured the CEO position via a board coup of the formerly Great Jihan Wu, master of chipsets, which split the BCH chain again, which broke the back of the community and its focus.
Clearly we don’t want that, one annal of epic crypto-failure poetry is enough.
Litecoin has Tenets. 4MB block-space per 10 minutes, that’s a Segwit 4x by default. Why change Bitcoin to Segwit2x when Litecoin exists and has massive exchange adoption, a lot of users still, user growth (doubling active addresses over the last few years), just solid fundamentals. Litecoin is actually a rebranding of the Bitcoin protocol to accompany a new little “b” bitcoin stock called litecoins, but the protocol itself, its design and technology are the 99.5% the same. That’s why we built on it, because the porting is a highly tractable problem.
Another thing Litecoin has going for it is the ability to do constitutional reform, rather than full blown Trotsky permanent revolution, a more measured but politically feasible path to reform exists on Litecoin precisely because so few hardliners care about it. Thus Jeremy Rubin’s OP_CTV, for starters, is much more envisionable on Litecoin, if it is not to be activated on Bitcoin by the end of 2023. Thus an OP_Wrap operation to sock bitcoins away in a UTXO that can only be spent if accompanied by an associated valid chain of spends of a rBTC or wBTC that is native, that is consistent to the same OP_Return marker, that extends the UTXO money to the uses of OP_Return tokens, that’s 90% probability going to be a reality on Litecoin before Bitcoin if it happens.
Of course Bitcoin is the big daddy. We expect a lively competition between the two TradeLayers. Like the twin heavens of Bytopia in D&D’s Planescape setting.
Of course having cross-chain atomic swaps between OP_Return properties is possible. What’s more, you can take the Trade Channel commits (for repeat trading ammo) and transfers (for moving committed tokens around channels) and unpublished trades and offsets to refresh those trades, and roll them up into an L3. You can take Lightning Network transactions and make ZK rollups of them as an L3 to do batch settlements. If you had an OP_Return wrapping of UTXO BTC or LTC, then the LN settlement could occur as an automatic dividend pay-out from a channel factory address to the OP_Return L2 and then those can be manually redeemed for underlying UTXO (albeit expensively, the idea is you’d have many other options for using it on the layers).
Could you make proofs of on-chain data and use that in a ZK-based L2? Yes. Could you make all these systems interoperate via more stringent bridges than the infamously hacked custodial bridges we’ve seen? Yes. Does this fit into smart contract platforms like Rootstock or Stacks? Yes, ZKs can reinforce their Bitcoin explorer libraries and give their smart contracts guaranteed oracles to trigger results.
The future for the oldtech is actually pretty bright, because we are distilling the best ideas of the newtech and applying it in a modular fashion that doesn’t add complexity to the foundation. TradeLayer has a role to play in that, though first it must launch, and establish liquidity in perpetual swaps, earning market share based on having the lowest cost. When you factor in opening Trade Channels, spending another miner fee on publishing, and add that to the half a basis point protocol fee, it’s not quite as cheap, launching on Litecoin also ameliorates that cost as the chain is still a quiet town and fees are minimal. To launch properly on Bitcoin, port testing QA notwithstanding, we need to get L2 functionality smartened up in a wallet implementation so that one can put your main margin trading balance on one commit tx, and then avoid publishing any further Bitcoin tx until they are ready to settle-up and cash out. Just a *simple* L2 implementation. Fortunately Bitcoin fees aren’t so high in 2022 but we do aim to do something about that. Longer-term, ZK based solutions are going to be hot.
If publishing a whole 22kb ZK validium directly to Bitcoin is not permissable, it would be possible to simply publish many OP_Return transactions that encode bits of it, so that relying on another data chain for a look-up isn’t needed, but more importantly so a more “native” on-chain oracle can use the data, it can be rolled up into its own ZK proof of chain characteristics that are used by smart contracts as state input. However there’d be 100 bytes of tx data in each 64 byte snippit. It’d bloat the overall chain space usage by 130%. Naturally the Bitcoin Core Developer approved way to put whole Validiums on the chain, would be via a merkelization. You’d turn that validum into something accessible along the leaves of a MAST construct and commit that to the chain instead of a plaintext Validum, it’d still weigh 22kb and some change but there’s that. Alternately enough soft-forked nodes can simply have no limit to their OP_Return payloads, or they can quickly verify the purported validums by reference to a data availability source, and then not relay (indeed it doesn’t sound entirely practical, but it’s practical enough for network latency). This is not a team founded on premises of aversion to putting data on chain, whereas other developers in the community have strong opinions about what is legitimate to publish on Bitcoin and what isn’t. But rest assured, Validiums are coming to Bitcoin.
What’s interesting about roll-ups vs. Validiums is the limited need for a data availability check and the ability to produce a faster/smaller-sized proof that has more limited scaling capacity, but maybe you don’t need that. Maybe you just want to take a few thousand LN transactions among a few hundred nodes from the month and quietly/cheaply get a ~1kb proof out about it, involving an algorithm that looks at the canonical data set of all those signed transactions, prooves they’re all valid etc. There’s still a place for roll-ups in the config space.
All of these app ideas could probably be implemented in Cairo, a language by Starkware that is a mix of C++, Assembly, Python (in the form of prover hints in which literal Python syntax is used) and Idris (a language that supports custom typing). Therefore, we are paying attention and training people to develop in Cairo. It’s the future.
Think of this post as our version of Vitalik’s end-game. We’re going to see a diversity of interoperating tools congeal around Bitcoin-like protocols to facilitate 95 or 98% of the Ethereum functionality. TradeLayer, being so weird and oddly overlooked by the rest of the industry, even the Synonym/OmniBolt projects didn’t bother trying to build an L2 multisig Dex or dYdX on Bitcoin, and here we have some unique atoms for the chemistry.