Web3 & DApp Development Fundamentals · บทเรียน

สถาปัตยกรรมบริดจ์

ล็อก-สร้างเหรียญและเผา

บทเรียน 2 จาก 413 ขั้นตอน

สถาปัตยกรรมบริดจ์ เป็นบทเรียน Web3 & DApp Development Fundamentals ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Web3 & DApp Development Fundamentals และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Web3 & DApp Development Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Bridge Design Categories

Bridges differ mainly in how they represent assets on the destination chain and who secures the transfer.

The main architectures are lock-and-mint, burn-and-mint, and liquidity pool bridges.

Lock-and-Mint Architecture

In lock-and-mint, the original asset is locked on the source chain and a wrapped version is minted on the destination.

The wrapped token is fully backed by the locked collateral in the bridge contract.

Source: lock 100 USDC in bridge
Dest:   mint 100 wUSDC to user

Burn-and-Mint Architecture

In burn-and-mint, the token is burned on the source chain and an equal amount is minted natively on the destination.

This requires the token contract on both chains to be controlled by the bridge, but avoids wrapped representations.

Source: burn 100 TOKEN
Dest:   mint 100 TOKEN (native)

Liquidity Pool Bridges

Liquidity pool bridges hold reserves of the same asset on both chains.

You deposit into the source pool and instantly withdraw from the destination pool — no minting, just a swap from existing liquidity for a fee.

Source pool: user deposits 100 USDC
Dest pool:   user receives 99.9 USDC
// 0.1% fee to liquidity providers

Who Verifies the Transfer?

Every bridge needs to verify the source event happened. Verification models include:

  • External multisig/federation
  • Optimistic with fraud proofs
  • Light client / native verification
  • ZK proofs

Multisig and Federated Bridges

The simplest (and historically most exploited) model uses a multisig of signers who attest transfers.

Security equals the honesty of those signers — if enough keys are compromised, funds can be stolen.

require signatures >= threshold
// e.g. 5 of 8 validators must sign

Optimistic Bridges

Optimistic bridges assume a transfer is valid and allow a challenge window where watchers can dispute fraud.

This adds a delay but reduces reliance on a trusted signer set.

Light-Client (Native) Bridges

A light-client bridge verifies the source chain's block headers and proofs directly on the destination chain.

This is the most trust-minimized approach — security comes from the chains themselves, not external parties.

ZK Bridges

ZK bridges use validity proofs to attest that an event occurred on the source chain.

The destination verifies a succinct proof, combining strong security with efficient on-chain verification — an emerging frontier.

Canonical vs Generalized Bridges

A canonical bridge is purpose-built for one chain pair (e.g. an L2's official bridge). A generalized bridge connects many chains through one protocol.

Generalized bridges are convenient but concentrate risk across all connected chains.

Putting It Together

Bridge architectures combine an asset model (lock-mint, burn-mint, or liquidity pools) with a verification model (multisig, optimistic, light client, or ZK).

The verification model largely determines safety. Next we study why bridges get exploited.

Quick Check

Test your bridge architecture knowledge.

Recap: Bridge Architectures

You learned that:

  • Asset models: lock-and-mint, burn-and-mint, liquidity pools
  • Verification: multisig, optimistic, light client, ZK
  • Light-client and ZK bridges are most trust-minimized
  • Canonical vs generalized bridges trade convenience for concentrated risk

Next: bridge security risks.

เริ่มต้นได้ฟรี

เรียนรู้ Web3 & DApp Development Fundamentals ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
29
บทเรียน
105

คำถามที่พบบ่อย

บทเรียน “สถาปัตยกรรมบริดจ์” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “สถาปัตยกรรมบริดจ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Web3 & DApp Development Fundamentals ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Web3 & DApp Development Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “สถาปัตยกรรมบริดจ์”

ล็อก-สร้างเหรียญและเผา คุณปฏิบัติ Web3 & DApp Development Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Web3 & DApp Development Fundamentals หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Web3 & DApp Development Fundamentals บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “สถาปัตยกรรมบริดจ์” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Web3 & DApp Development Fundamentals นี้ได้ไหม

ได้ บทเรียน Web3 & DApp Development Fundamentals ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. แนวคิดข้ามเชน
  2. สถาปัตยกรรมบริดจ์
  3. ความเสี่ยงด้านความปลอดภัยของบริดจ์
  4. โพรโทคอลการส่งข้อความ
← กลับไปที่ Web3 & DApp Development Fundamentals