2024.5.6 - 2024.5.12
2024.5.11
SHA256 has been further optimized to 296K per chunk, seehttps://github.com/BitVM/BitVM/pull/66. Currently, this PR is still under review.
The PR still uses u4 as the basic unit, but these optimizations are achieved by reducing unnecessary value copying or moving on the stack.
This PR adds around 1866 lines of code, implementing optimized u4 version of sha256, and introduces an additional library for debugging BTC scripts athttps://github.com/FairgateLabs/rust-bitcoin-script-stack.
The library for debugging BTC scripts is speculated to be inspired by the visual debugging of BitIDE (js) developed by QED protocol, which is worth referencing. (A demo of BitIDE implementing blake3 is available athttps://bitide.qedprotocol.com/?importProject=https%3A%2F%2Fbtcscripts.qed.run%2Fexamples%2Fhash_demo.json&openFile=scripts%2Fblake3_demo_1.js).
2024.5.10
Bitlayer@BitlayerLabshas completed its first NFT minting, and the community now has over 500,000 users! NFTs can be purchased on OKX:https://www.okx.com/zh-hans/web3/marketplace/nft/collection/bitlayer/bitlayer-lucky-helmet. BitLayer is the first Bitcoin security Layer2 based on BitVM.
Citrea@citrea_xyzposted indicating the use of RISC0 technology to generate two types of proofs: one for Bitcoin light client and the other for batch proofs of L2 transactions.https://twitter.com/citrea_xyz/status/1788902191799156940
Citrea's proof generation mechanism is specifically tailored for Bitcoin and BitVM. Citrea operates on top of a STARK-based zkVM with recursive capabilities, incorporating RISC Zero, and utilizes two different types of proofs:Batch Proofs: Batch proofs are generated periodically, typically every few Bitcoin blocks. Citrea's batch proof circuit is configured to scan batch root ciphertexts in Bitcoin blocks through inclusion and soundness proofs. If present, it inputs the L2 batch causing the batch root and proves the validity of the L2 batch. The proof output consists of the batch, initial state root, latest state root, and the state differences induced by scanning the Bitcoin block's block hash. The proof with outputs is etched onto Bitcoin.Light Client Proofs: Light client proofs recursively validate batch proofs and provide a single proof for the entire Rollup history, enabling trustless instant light clients. The light client proof circuit inputs previously generated light client proofs, a set of batch proofs containing inclusion and soundness proofs, and a set of Bitcoin block headers corresponding to the recorded batch proofs. The circuit recursively validates each batch proof and light client proof, asserting that the latest state root of proof N-1 equals the initial state root of proof N. This logic ensures no state transitions are skipped, resulting in a state root identical to the actual Rollup state root.
By recursively validating previous light client proofs using batch proofs, light client proofs can be generated at any time.
Light client proofs are broadcasted in a peer-to-peer network and etched onto Bitcoin.
Light nodes can listen to the peer network or only track the latest Bitcoin headers. They validate the complete Rollup history with the latest evidence they find and provide trustless access to the state root.
Citrea's circuits primarily prove two distinct logics: execution and block space. During batch proof generation, both execution and block space are proven. During light client proof generation, block space and batch proof validation are proven.Execution Proof: Citrea runs the state transition function of the rollup, which is a slightly broader logic of EVM included within the zk circuit. The circuit inputs the previous state of Rollup, the blocks of the new batch, and outputs the state difference between the pre-state and post-state after applying the batch.Block Space Proof: Block space proof is a novel concept used in Citrea. The block space proof logic is a custom zk circuit that scans Bitcoin blocks, extracts state roots or Citrea batch proofs, and enforces transactions from it. In batch proofs, it asserts the accuracy of the state root, and in light client proofs, it verifies the batch proof (if present). The Bitcoin block scan within the circuit is completed by given inclusion and soundness proofs and cross-checked with corresponding Bitcoin block headers.Citrea combines execution proofs and block space proofs into a single circuit for batch proofs. Standalone batch proofs are only beneficial for full nodes. To run light nodes on a system with only batch proofs, light nodes must individually check proofs for each Bitcoin block, which is impractical for light clients due to bandwidth and storage requirements.In Citrea, due to the recursion of its light client proofs on batch proofs and block space proofs, users have trustless light clients. Anyone with the last few Bitcoin blocks or connected to the peer-to-peer network can extract Citrea light client proofs and ensure it represents the only valid fork of the chain and verifies every state transition since the Citrea genesis block.
2024.5.6
@rot13maxiexplained in the Bitcoin++ talk (https://twitter.com/fede_intern/status/1787191430110151060)
Introduce how op_cat can be used to implement the principle of vaults.
He also suggested that in the future, it might be possible to extend a finite state machine through the implementation of vaults, recommending the idea of MATT (Merkleize All The Things) discussed in Bitcoin mailing lists. More details are available athttps://merkle.fun/.
Last updated
