Draken

Draken

Keep It Simple, Stupid!
HomeArchives

Week 3 Learning Record

21
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
The document discusses a decentralized universal notarization protocol that defines rules for multi-signatures, staking, and zero-knowledge proof (ZKP) verification. In a hackathon context, DApps serve as tools to demonstrate the protocol's capabilities, which hold greater value and potential. The protocol aims for "verifiable, permissioned anonymity" rather than complete anonymity, using mechanisms like Decentralized Identifiers (DID) and Soulbound Tokens (SBT) to map real-world identities onto the blockchain. Additionally, the author revisits the Uniswap v3 source code, comparing it to v2. Key features of v3 include concentrated liquidity, customizable price ranges, multi-tiered fees, and improved oracle mechanisms for time-weighted average prices (TWAP). The document also highlights the importance of the price tick mechanism and discusses the reasons for EVM's lack of support for floating-point numbers, such as uncertainty, precision loss, verification difficulties, and high gas costs. Uniswap addresses these issues using a Q64.96 format for representing numbers.

Hackathon#

Self-examination, a decentralized universal notarization protocol, which defines the rules for multi-signature, staking, and ZKP verification, is the protocol layer. In the hackathon, the DApp is merely a tool to demonstrate the functionality of this protocol. The protocol has greater value and broader potential. Consideration of the DApp demonstration process is the exchange of financial data and how to address anonymity.
Solution 1: Identity on-chain (DID/SBT)
Solution 2: "Human KYC" for notaries
In financial scenarios, this protocol does not pursue complete anonymity. It seeks "verifiable, permissioned anonymity." Through mechanisms like DID/SBT, it maps real-world identity permissions onto the chain, allowing the protocol to determine "this is a request from a permitted entity," thus addressing the trust issues brought by anonymity.

Source Code Learning#

This week I revisited the source code of Uniswap, mainly reviewing version 3 while comparing it with version 2 for learning purposes. Version 3 concentrates liquidity, allowing liquidity to set its own price range, thereby improving capital utilization. Version 3 introduces multi-tiered fees to meet different risk preferences. It improves the oracle, introducing a more secure mechanism that supports time-weighted average price (TWAP) over any range; it provides an "accumulated snapshot" mechanism (observe() function); it can be directly used as an on-chain price reference, reducing the attack surface. Tick & Tick Spacing (price scale mechanism) is crucial when studying version 3, related to core mathematical logic, especially √P. This also involves project design philosophy. Additionally, I diverged into some mechanisms of EVM, such as why floating-point numbers are not used, how many transaction requests EVM can execute concurrently, etc.
Reasons for not supporting floating-point numbers:

  • Uncertainty: Floating-point operations can lead to different results across nodes due to rounding, affecting consensus.
  • Precision loss: Ethereum transaction settlement precision reaches up to 18 decimal places, which floating-point numbers cannot accommodate.
  • Difficult to verify: Floating-point numbers cannot reproduce completely consistent results on-chain (different compilers/platforms may yield different results).
  • High gas costs: Floating-point simulation operations consume a large amount of computational power and storage.
    Uniswap's solution is to use Q64.96 representation (64-bit integer + 96-bit decimal).
Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.