As an enthusiast of protocol design, I write for those who wonder what separates @Lighter_xyz from @HyperliquidX. The fundamental difference lies in source of truth for their trades 🧵👇👇 @HyperliquidX relies on Social Consensus: trades happened because 24 validators agree it happened. This allows for high speed and human intervention (rollbacks), but requires TRUST. @Lighter_xyz relies on Cryptographic Validity: trades happened because a Zero-Knowledge circuit mathematically proves the matching engine respected the order book rules. This eliminates TRUST but enforces rigid adherence to "code is law." 1. Proof of Scope: what is actually being verified when a batch of trades is finalized? @Hyperliquid (Validator Consensus): - Mechanism: it operates as a sovereign Layer 1 blockchain using a Tendermint-style consensus. The "scope" of verification is the state root signed by a supermajority (2/3) of the validators. - Validators attest to the final state (balances). They do not cryptographically prove that the matching engine followed Price-Time Priority. You TRUST that the validator set is running the correct binary and not colluding to reorder transactions. - Hence this is a "Trusted Setup." If the validators decide to alter the history (as seen in the $JELLY pair rollback), they have the scope to do so to protect the ecosystem. @Lighter (Execution Logic): - Mechanism: it is a ZK-Rollup that goes beyond standard "settlement proofs." Most rollups only prove $Balance_{new} = Balance_{old} + Delta. Lighter uses a ZK Circuit to prove the Matching Engine Logic. - The proof contains constraints representing the order book rules. It proves: >>Existence: Alice’s order existed at Block N. >>Optimality: Bob’s order was the best available price. >>Execution: The match occurred immediately. - It is mathematically impossible to generate a valid proof if the sequencer skipped a better price to front-run a user. The circuit would evaluate to FALSE (like $2+2=5), and the proof generation would fail. 2. Matching Engine: how are orders paired? @Hyperliquid (Black Box / Validator Controlled): - The matching engine runs on the validators' hardware. While high-performance, it acts as a "Black Box" to the user until the block is finalized. - MEV & Front-running: as the validators control the ordering of transactions within a block, they theoretically possess the ability to extract MEV by front-running or sandwiching user orders. Users have to TRUST and rely on the reputation of the 24 validators and the protocol's incentives to prevent this. - The advantage here is adaptability. If a bug or market exploit occurs, validators can coordinate a manual intervention (the $JELLY rollback) to save the insurance fund. @Lighter_xyz (Mathematically Verified): - The matching engine is codified into a ZK Circuit. The sequencer (server) executes trades off-chain for speed, but it must produce a cryptographic receipt (ZK Proof) that verifies the execution followed the code. - MEV Resistance: if the sequencer tries to insert a bot order to give a worse price, the inputs to the circuit change, and the proof becomes invalid. - The downside is the lack of flexibility. If the matching engine has a logic error that allows a fair but devastating trade (e.g., a market manipulation that is technically legal by the code), there is no human factor that can "rollback" the chain without a hard fork of the smart contracts on @Ethereum. 3. Verification: who has the final say on whether a trade is valid? @Hyperliquid: - The 24 validators act as the judge, jury, and executioner. - Jurisdiction: They operate on their own chain. There is no "Higher Court." If a user disagrees with the validators' decision to freeze assets or rollback trades, there is no recourse. The bridge to @Arbitrum/ @Ethereum is controlled by the same entity/logic; if the @Hyperliquid chain halts, the bridge halts. @Lighter_xyz: @Ethereum validators are the judge - Jurisdiction: Lighter submits the ZK proof to a smart contract on @Ethereum, and the validators make the final decision - The contract runs a verifyProof function. This is a binary operation (True/False). >>If True, the state updates. >>If False, the transaction is rejected. The @Ethereum network effectively says, "The math does not check out, we reject this state update." The @Lighter_xyz sequencer cannot force a fraudulent state update onto @Ethereum. 4. Censorship Resistance: the safety of funds in worst-case scenarios (exchange shutdown or malicious takeover). @Hyperliquid (Low - No Escape): - If the @Hyperliquid validators censor your address or the chain goes offline, your funds are trapped. Since the assets reside on the @Hyperliquid L1, you cannot interact with them without the validators' cooperation. You cannot "withdraw" to @Ethereum if the Hyperliquid chain stops processing your withdrawal requests. @Lighter (High - "Exodus Mode"): - The Lighter sequencer goes offline, censors your withdrawal, or shuts down the website, you interact directly with the @Lighter_xyz contract on @Ethereum L1. - Force Withdrawal: You call a function on L1 to demand withdrawal. If the @Lighter_xyz sequencer does not process this within a set time (e.g., 24 hours), the contract enters Exodus Mode. - In Exodus Mode, users can withdraw funds directly from the @Ethereum bridge contract using data available on-chain (Data Availability), bypassing the @Lighter_xyz sequencer entirely. This guarantees self-custody even if the exchange disappears. Gigabrains feel free to add more: @vnovakovski @Route2FI @KevinSusanto @coinmamba @dustybc @y95277777 @mrblock
· 9.1K Views
