Bridging và MEV

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Trong bài viết này, mình sẽ giới thiệu các bạn đến MEV và Bridging giữa các blockchain khác nhau. MEV Khái niệm MEV là Maximal Extractable Value. Đây là giá trị lớn nhất có thể thu được từ việc sản xuất các block vượt qua các phần thưởng block tiêu chuẩn và phí gas bằng việc thêm, loại bỏ, thay đổi thứ tự các Tx trong khối. Searchers Searchers là những người post các Tx để cân bằng thị trường, thanh lý và lấy lợi nhuận. Ví dụ: Uniswap DAI/USDC có ExchangeRate là 1.001, trong khi Sushiswap là 1.002. Lúc này, Searchers có thể vay 1 khoản DAI, đổi DAI thành USDC trong Uniswap rồi dùng nó để đổi lại DAI trong Sushiswap. Ngoài ra, còn nhiều cách để nhận MEV từ việc thay đổi chuỗi Tx (Bundle).\ Vấn đề của MEV Khi searchers post Tx lên mempool, những điều sau có thể xảy ra: Validator: có thể tự tạo Tx của họ với cách tương tự Tx của searchers nhưng người thụ hưởng sẽ là validator đó và đặt nó trước Tx của searchers. Searchers khác: tự tạo Tx của họ nhưng với phí gas ưu tiên (maxPriorityFee) cao hơn. (Thường được thực hiện bởi các bots). Hậu quả Với Honest users: Việc submit lại nhiều lần các Tx với phí gas ưu tiên cao hơn cho đến khi validator chọn được 1 Tx trong ít giây (Đấu giá gas) sẽ dẫn đến việc tắc nghẽn và phí gas cao. Với consensus: Tấn công vào chuỗi dài nhất. Lý do vì MEV sẽ tạo lợi nhuận cho miner nhiều hơn phần thưởng khối. Gây ra Centralization : Các validator có thể trộm MEV Tx từ các searchers. Do đó nhiều searchers chỉ gửi Tx cho 1 vài validator mà họ tin tưởng. Lâu dần sẽ khiến một số Validators giữ số lượng lớn các Tx. Giải pháp: Proposer Builder Separation (PBS) Mục tiêu: Giảm việc đấu giá gas Thay vào đó, tạo ra một open market mà searchers cạnh tranh về vị trí bundle của họ trong block. Mọi validators có thể kiếm MEV payment từ searchers. Từ đó tránh việc centralization. Minh hoạ: Builder : thu thập các Bundles và Txs sau đó build 1 block. (trong block bao gồm feeRecipient (MEV offer) cho validator). Relay : thu nhận các blocks, chọn block với MEV offer lớn nhất: Gửi block header (và MEV offer) cho block proposer. Không tiết lộ nội dung bên trong khối cho propser. Proposer : chọn offer tốt nhất và kí header với staking key của nó. Sau đó Relay sẽ tiết lộ nội dung block. Sau đó proposer sẽ gửi block lên network. Cụ thể Searchers sẽ phải thắng 2 cuộc đấu giá để bundle của họ được đưa vào block (là builder auction và relay auction). Searchers phải làm việc với builder mà họ tin tưởng và phải tin tưởng relay làm việc cùng với builder đó. Searchers không cần phải tin Proposer. Proposer không thể bỏ lỡ slot. Nếu relay không đưa cho họ block hợp lệ, proposer sẽ tự tạo block từ mempool của nó. Khi proposer kí header, nó không thể kí khối khác, nếu không sẽ bị slash. Một số ví dụ về relay là Flashbot, BloXroute. Khả năng tương tác giữa các blockchain Tương tác : Cho phép user chuyển tài sản qua các chain khác nhau. Kết hợp : Cho phép 1 DApp từ 1 chuỗi có thể gọi DApp từ chuỗi khác. Để làm được điều này, cần sử dụng các Bridges. Ví dụ: Chuyển BTC trong Ethereum Sử dụng wrapped coins. Với wBTC Alice lock 1 BTC trong custodian’s BTC address Custodian trung gian sau khi thấy điều này, sẽ gửi msg đến ERC20 (bridge contract), xác nhận ERC20 sẽ tạo wBTC cho Alice trong Ethereum Sau khi dùng xong, Alice sẽ burn wBTC. Custodian trung gian sau khi thấy điều này, sẽ gửi msg đến custodian BTC. Custodian BTC sẽ unlock 1 BTC cho Alice. Vấn đề đưa ra là liệu các Custodian có tin tưởng được không? Để giải quyết, ta sẽ sử dụng tBTC như sau: Chọn ngẫu nhiên 3 custodian và tạo P2PKH Bitcoin address cho Alice. Khoá chữ ký 3-3 là bí mật giữa 3 người. Alice gửi BTC vào địa chỉ P2PKH, nhận tBTC Custodians cần khoá 1.5x ETH stake cho BTC họ quản lý. Nếu BTC locked mà bị mất, Alice sẽ lấy staked ETH. 2 loại Bridges Loại 1: lock-and-mint bridge SRC ⇾ DEST: user lock tiền ở SRC, wrapped token sẽ được mint ở DEST. DEST ⇾ SRC: fund khi được burned từ DEST, thì SRC sẽ release lock. Loại 2: liquidity pool bridge Cả 2 phía đều có Liquidity provider SRC -> DEST: người dùng gửi funds ở SRC, số tiền tương đương sẽ được giải phóng từ DEST. Bridging smart chain Bước 1: Tạo một hệ thống message xuyên chuỗi an toàn Bước 2: Xây 1 bridge sử dụng hệ thống message Minh hoạ Có 2 loại hệ thống message: Externally verified : các bên bên ngoài (Trustee) sẽ xác minh các message trên chuỗi S. RelayerT chuyển msg cho người nhận khi các trustees đều kí ⟹ nếu DApp-Y tin trustees, thì sẽ biết được DApp-X gửi msg. Nếu trustee kí và post fake msg cho RelayerT thì những bên offchain có thể gửi signature của trustee cho relayerS, khiến trustee bị slashed. Onchain verified : chuỗi T verifies block header của chuỗi S. Oracle gửi msg cho relayerT, cùng với finalized block header của chuỗi S. Oracle sẽ không được gọi là trustee vì nó chỉ chuyển các finalized block. RelayerT sẽ chạy client nhẹ để xác thực xem chuỗi S có nhận msg mà gửi đi hay không. Tuy nhiên, vấn đề đặt ra là việc chuỗi T verify state của chuỗi S sẽ tốn gas. Để giải quyết điều này, cần sử dụng zkBridge: sử dụng SNARK để giảm việc tính toán cho relayerT. Tạm kết Với briding, trong tương lai sẽ giúp việc di chuyển các assets nhanh và rẻ qua các chain, khiến các project thanh khoản sẽ được thực hiện ở trong tất cả các chain.

Blockchain · 2023-08-29

Quyền riêng tư trên blockchain và Zk-SNARK

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Trong hệ thống tài chính, việc riêng tư là điều cần thiết. Một vài ví dụ như: Một nhà sản xuất không muốn tiết lộ số tiền họ trả cho nhà cung cấp của mình cho các bộ phận, Người dùng cuối cần quyền riêng tư để thuê, quyên góp, mua hàng,… Do đó, blockchain không thể phát huy hết tiềm năng nếu không có một số Tx riêng tư. Sự riêng tư trong các blockchain Với Ethereum, mọi số dư đều công khai. Trong các DApps, code và state cũng công khai cho người dùng. Ngoài ra, các Tx cũng nối đến các account. Với Bitcoin, dữ liệu Tx có thể được sử dụng để kết nối 1 địa chỉ tới 1 định danh vật lý. Tx riêng tư trên blockchain công khai Chúng ta có thể sử dụng commitments và zero knowledge proof để làm điều này. Committed data : cam kết ngắn (ẩn) ở trên chuỗi. Proof 𝝅 : succinct Zero knowledge (Zk) proof: Committed Tx data nhất quán với trạng thái commited hiện tại. Committed update state thì đúng. Từ đó, ai cũng có thể xác thực 𝝅. Review: Commitment Được sử dụng với nhiều mục đích, ví dụ Đấu giá kín. Người tham gia cam kết giá, sau khi hết thời gian thì mọi người sẽ mở cam kết của họ. Cú pháp 2 thuật toán: commit(msg, r) -> com. Trong đó, r là randombit, com là string ngắn verify(msg, com, r) -> reject / accept. Tính bảo mật Binding : Không thể tạo 2 valid openings cho com. Tức là: tạo ra com, (m1, r1), (m2, r2) mà: verify(m1, com, r1) = accept. Và verify(m2, com, r2) = accept với m1 ≠ m2. Hiding : Com không tiết lộ gì về data đã committed. Tức là com sẽ độc lập với m. zk-SNARK là gì? Các khái niệm Để verify 1 Tx, Validator cần phải xem thông tin trong Tx đó và kiểm tra xem có thoả mãn không. Nhưng nếu các Tx là private thì Validator sẽ kiểm tra như thế nào? Lúc này, zk-SNARK được ra đời. SNARK : là 1 proof ngắn gọn để chứng minh 1 statement là đúng. Ngoài ra, nó cần nhanh để xác thực bởi người xác thực. Ví dụ: statement: “Tôi biết một m mà SHA256(m) = 0”. zk-SNARK : là SNARK không tiết lộ gì về nội dung. Ví dụ trong statement kia thì zk-SNARK sẽ không tiết lộ gì về giá trị của m. Ứng dụng: Private Tx zkBrigde: nối các chuỗi khối tính riêng tư trong zk-Rollups Kĩ thuật zk-SNARK Arithmetic Circuits (AC) Cho 1 trường hữu hạn: $𝔽={0, …, 𝑝−1}$ với p là số nguyên tố > 2. Arithmetic Circuit: C: $𝔽^𝑛 ⇾ 𝔽$. C lấy input là list gồm n phần tử thuộc F, output là 1 phần tử thuộc F. |C| = số gates trong mạch C. Ví dụ: C_hash(h, m) = 0 nếu SHA256(m) = h, $!= 0$ nếu ngược lại. C_sig(pk, msg, σ) = 0 nếu chữ kí σ là hợp lệ trên msg với pk. Argument System Cho một AC: C(x, w) -> F với: x: là statement công khai w: secret witness. Prover P cần thuyết phục các Verifier V rằng tồn tại w mà C(x, w) = 0 nhưng không muốn gửi w vì lý do bảo mật. Có 2 loại argument systems: Interactive vs Non-interactives. Interactive: P <-> V tương tác với nhau nhiều lần để V đồng ý. Cách này chỉ áp dụng với hệ thống có ít V. Non-interactive: P chỉ gửi duy nhất 1 msg là proof cho V. Cách này có ích khi có nhiều Verifier (Ví dụ nhiều Validator muốn xác thực 1 Tx). NARK: Non-interactive Argument of Knowledge Với mạch C(x, w) ⇾ 𝔽. Preprocessing : S(C) ⇾ public parameters(Sp, Sv). Minh hoạ: Một preprocessing NARK là bộ 3 (S, P, V): S(C) ⇾ public parameters(Sp, Sv). P(Sp, x, w) ⇾ proof 𝜋 V(𝑣𝑝, 𝒙, 𝝅) ⇾ accept / reject Yêu cầu Complete: ∀𝑥, 𝑤: $𝐶(𝒙, 𝒘) = 0 ⇒ Pr[ V(𝑣𝑝, 𝑥, P(𝑝𝑝, 𝒙, 𝒘)) = accept] = 1$. Argument of knowledge: V accepts ⇒ P biết 𝑤 Zero knowledge: (𝐶, 𝑝𝑝,𝑣𝑝 ,𝒙, 𝜋) không tiết lộ gì về 𝒘 Succinct Một NARK gọi là SNARK khi việc tạo ra và xác minh proof với thời gian nhanh: S(𝐶) ⇾ public parameters (S𝑝, S𝑣) P(𝑝𝑝, 𝒙, 𝒘) $\rightarrow$ short proof 𝜋; $\lVert 𝜋 \rVert =𝑂_𝜆(𝐥𝐨𝐠⁡(\lVert𝑪\rVert))$ V(𝑣𝑝, 𝒙, 𝝅) nhanh để thẩm định: $time(V) = 𝑂_𝜆 (\lVert 𝑥 \rVert, 𝐥𝐨𝐠⁡(\lVert 𝑪 \rVert))$. Do đó, với SNARK thì việc đọc toàn bộ mạch C là không kịp thời gian. VÌ vậy cần bước preprocessing. Tóm lại: SNARK: bộ (S, P, V) thoả mãn: Complete, Argument of knowledge, Succinct. zk-SNARK: SNARK có zero knowledge. Các loại Preprocessing trusted setup per circuit: S(C) sử dụng data bí mật (Ví dụ: randombit r). trusted but universal: Randombit r độc lập khỏi C: S = (S_init, S_index) với: 𝑆_𝑖𝑛𝑖𝑡 (𝜆;𝑟) ⇾ U: 1 lần duy nhất. 𝑆_𝑖𝑛𝑑𝑒𝑥 (U,𝐶) ⇾ (S𝑝, S𝑣): Không chứa secret data. Argurment of knowledge P biết w nếu w có thể được extracted từ P. Bộ 3 (S, P, V) là Argurment of knowledge với mạch C nếu: A = (A0, A1) là adversary mà có thể bị extracted thông tin: S(C) ⇾ (Sp, Sv), A0(Sp) ⇾ (x, st) 𝜋 ⇽ A1(𝑝𝑝, 𝑥, st): Pr[V(vp, 𝑥, 𝜋) = accept] > 1/10^6 (không đáng kể ) Có extractor E (sử dụng A1 là blackbox) và tạo ra được w bằng tương tác với A1(Sp, x, st). Zero knowledge Proof 𝜋 không tiết lộ về 𝒘 nếu Verifier tự tạo 𝜋, hay Verifier không học được gì từ proof 𝜋. Tức là: Tồn tại 1 hàm Sim() sao cho: (S𝑝, S𝑣, 𝜋) ⇽ Sim(𝐶,𝑥). Hay Sim() có thể tạo ra proof 𝜋 mà không cần w. Lời kết Ở trên là sơ lược về tính riêng tư trong Blockchain và cái nhìn tổng quan về zk-SNARK.

Blockchain · 2023-08-20

Mở rộng Blockchain (Phần 2)

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Trong bài viết hôm nay, mình sẽ giới thiệu đến mọi người một kĩ thuật giúp tăng tốc độ các Tx trong mạng blockchain. Đó là Rollups. Ý tưởng Trong layer-1 của blockchain như Ethereum chứa world state. Khi một giao dịch được đưa vào, world state sẽ bị thay đổi. Từ đây, ý tưởng cơ bản của Rollup là hợp hàng trăm Tx lại thành một Tx duy nhất, từ đó giúp tăng tốc độ lên khoảng 100 lần. Ta có hình minh hoạ như sau: Từ đây, ta gọi Rollup state là L2, để phân biệt với L1 (layer-1 của blockchain). Rollup contract ở L1 sẽ giữ các tài sản và Merkle state root của các Rollup account. Rollup state chỉ bao gồm số dư của các Rollup account. Hiệu năng Chuyển tiền trong 1 Rollup Chuyển tiền trong 1 Rollup (L2 -> L2) rất dễ dàng. Các coordinators chỉ cần cập nhập lại Merkle Root của Rollup Contract trên L1 là xong. Chuyển tiền từ funds đến Rollup Chuyển tiền từ funds đến Rollup (L1 -> L2) thì chậm và đắt. Lý do vì cần phải update các state trong L1, số dư trong contract và cả trong Rollup và cập nhập lại Root của contract đó. Chuyển tiền ra khỏi Rollup Chuyển tiền ra khỏi Rollup cần phí gas thêm từ L1 trong quá trình chuyển vì cần post nhiều dữ liệu. Chuyển tiền từ 2 Rollup Nếu chuyển tiền từ 2 Rollup (L2 -> L2’) mà qua L1 thì sẽ rất đắt, nhưng nếu qua 1 cầu trực tiếp L2 <=> L2 thì sẽ rẻ. Chạy contract trong Rollup Khi contract chạy trong Rollup (Ví dụ Uniswap), thì việc tương tác với contract đó sẽ rẩt rẻ cho người dùng. Coordinator duy trì trạng thái của tất cả contracts trong hệ thống Rollup: Nó cập nhập Uniswap Merkle Leaf mỗi khi 1 Tx nào đó đến Uniswap Ghi update cho Rollup state root trên L1. Rollup có chức năng giống Ethereum, nhưng không có cơ chế đồng thuận vì nó dựa vào L1 để chứng thực trạng thái hiện tại. Các vấn đề Vấn đề 1 : Điều gì xảy ra nếu Coordinator không trung thực. Nó có thể lấy hết tiền trong Rollup hoặc tạo các giao dịch giả. Vấn đề 2 : Nếu Coordinator ngừng cung cấp dịch vụ ? Làm sao để lấy lại trạng thái Rollup để đưa cho Coordinator mới. Các phương án giải quyết Vấn đề 1: Coordinator không trung thực Coordinator không thể lấy tiền từ Rollup users, vì L1 sẽ xác minh update trạng thái của Rollup bằng cách kiểm tra xem tất cả các Tx có valid và được ký hợp lệ bởi người dùng hay không. Để làm điều này một cách rẻ, có thể có các cách tiếp cận sau: Validity Proofs (còn gọi là zk-Rollup) Khi coordinator gửi updated root và Tx List cho L1, nó cần gửi kèm theo một SNARK proof cho valid Tx để chứng minh tập hàng trăm các Tx này là hợp lệ. SNARK proof là loại proof ngắn và nhanh để xác minh, từ đó giúp việc xác minh trên L1 trở nên rẻ. (với sự giúp đỡ của EVM) Bao gồm: Public statement: (old state root, new state root, Tx list) Witness: (state trước - sau của những tài khoản bị thay đổi, bằng chứng Merkle, chữ kí của user) SNARK proof sẽ chứng minh rằng: Tất cả chữ ký trên đều valid Tất cả bằng chứng Merkle đều valid Trạng thái sau = trạng thái trước + Tx. zkEVM Khi một contract (Uniswap) chạy trong Rollup: Coordinator sẽ tạo 1 SNARK proof về việc thực hiện đúng 1 chương trình EVM. Đó gọi là zkEVM. Tạo bằng chứng thì sẽ yêu cầu rất cao về tính toán nhưng khi xác minh thì lại rất nhanh. Có 2 chức năng của zkEVM là: Chứng minh EVM bytecode chạy đúng Biên dịch Solidity to SNARK-friendly circuit. Kết quả Rollup contract đảm bảo coordinator không thể gian lận và sẽ chấp nhận các update nếu có proof phù hợp Ai cũng có thể làm coordinator nếu có đủ sức mạnh tính toán Fraud proof (còn gọi là Optimistic Rollup) Coordinator sẽ stake 1 khoản vào L1 Rollup Contract Coordinator sẽ đưa updated root lên L1 mà không cần bằng chứng Nếu update không valid, trong vòng 7 ngày ai cũng có thể chứng minh điều này bằng việc gửi fraud proof. Nếu fraud proof là đúng, coordinator sẽ bị Slash, ngược lại người gửi proof sẽ tốn phí. Để chứng minh Fraud đến Rollup contract trong L1, ta sẽ sử dụng Binary Search. Việc Coordinator và Người gửi Proof (A) tạo ra state(n) và state(n’) khác nhau buộc L1 cần kiểm tra xem ai mới là người đúng. Do đó, sử dụng Merkle tree và tìm kiếm nhị phân, với việc chia đôi từ state(n/2), state(n/4)… có thể dễ dàng tìm được xem state nào bị sai sau Log2(n) round. Tuy nhiên, cách này gặp 1 số khó khăn như: Giao dịch chỉ giải quyết sau 7 ngày (Sau khi hết hạn gian lận) Khi 1 bằng chứng Fraud được chấp nhận, các Tx sau phải được gửi lại Kết quả Có thể dễ dàng đưa smartcontract vào optimistic Rollup Thông lượng Tx cao: ~ 4000Tx / s Ai cũng có thể làm coordinator và verifier Giải quyết giao dịch chậm 7 ngày. Vấn đề 2: Coordinator ngừng cung cấp dịch vụ Cần tạo Coordinator mới, nhưng lại cần trạng thái mới nhất của Rollup. Ta thấy, Rollup state có thể phục hồi từ dữ liệu trong L1 bằng việc đọc các msg và re-excecute Tx. Nhưng việc này sẽ rất đắt vì tương tác nhiều trên L1 và cần nhiều dữ liệu. Để giảm Tx fees: Lưu L2 state root trong L1 Lưu Tx data với Data Availability Committee (DAC): Gồm tập hợp các node tin cậy giữ cho data available Rẻ hơn lưu ở L1 L1 chấp nhận update khi và chỉ khi tất cả các node trong DAC đều kí. Từ đó giúp đảm bảo các member trong DAC đều chấp nhập dữ liệu Tx. Tạo 1 coordinator mới phụ thuộc vào tính khả dụng của DAC Validium 1 L2 sử dụng DAC để lưu trữ và Validity proof (SNARKs): Phù hợp cho tài sản giá trị thấp Chỉ các thành viên DAC mới thấy được dữ liệu Điều gì xảy ra nếu Coordinator từ chối 1 Tx Người tạo có thể post Tx trực tiếp lên L1 Rollup contract. L1 Rollup contract chỉ chấp nhận update khi mà update có cả Tx trên. Từ đó dẫn đến toàn bộ Rollup bị đóng băng. Lời kết Ở trên đây là các cách được áp dụng để tăng tốc độ Tx trong blockchain.

Blockchain · 2023-08-19

Mở rộng Blockchain (Phần 1)

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Với Bitcoin, tốc độ thực hiện giao dịch chỉ có khoảng 7 Tx / sec, còn với Ethereum, con số này là 15. Trong khi đó, với VISA là 2000, Paypal là 200. Vậy để các loại Blockchain này được sử dụng nhiều trên thế giới, cần phải có những giải pháp để tăng tốc độ các giao dịch. Trong bài viết này, mình sẽ giới thiệu đến một cách là sử dụng Payment Channel, hạn chế tương tác với chuỗi càng ít càng tốt, giúp tăng tốc độ. Payment Channel: Ý tưởng cơ bản A và B đang muốn giao dịch với nhau. A gửi cho B 5 lần, mỗi lần là 0.01 BTC, là 5 Txs. Thay vì làm như thế, có thể làm như sau: A gửi cho B 1BTC. Sau 1 khoảng thời gian (ví dụ 1 tháng), B sẽ trả lại số BTC dư mà chưa dùng. Vậy số giao dịch chỉ giới hạn đến 2. Unidirectional Payment Channel: Kênh thanh toán 1 chiều Ta có: UTXO A: 1BTC. Tx1: 0.99 cho A/ 0.01 cho B từ UTXO A. Tx2: 0.98 cho A/ 0.02 cho B …. Tx5: 0.95 cho A/ 0.05 cho B Xong xuôi, B post Tx5 lên Blockchain. Nhưng có vấn đề xảy ra là nếu A sử dụng UTXO trước khi B post lên thì Tx5 mà B post lên sẽ không hợp lệ. Do đó, cần sử dụng 1 địa chỉ chung UTXO AB có dạng Multisig 2-2. Điều này sẽ ngăn chặn việc A dùng UTXO vì chưa có chữ kí của B. Nhưng nếu B không post Tx5 lên chuỗi thì sao? Liệu A có lấy lại được 0.95 BTC. Để giải quyết vấn đề này, cần sử dụng một time-locked Tx, đảm bảo sau một khoảng thời gian, nếu B không post Tx5 lên, thì A sẽ lấy lại được 1BTC (B phải gửi cho A). Ngoài ra, Tx này phải được kí trước khi đưa BTC vào trong AB. Minh hoạ: Sau khi trả hoặc lấy lại tiền, kênh sẽ đóng. Bidirectional Payment Channel: Kênh thanh toán đa chiều Không sử dụng 2 kênh thanh toán 1 chiều thay thế. Thay vào đó, ta sẽ sử dụng contract. Trên Ethereum A và B sẽ tạo một contract chung, mỗi người đóng góp 0.5 ETH. Lúc này, trạng thái của contract sẽ là: A: 0.5 ETH B: 0.5 ETH Nonce: 0. Off chain: B gửi 0.1 ETH cho A bằng cách cả 2 ký vào state mới: A: 0.6, B: 0.4, Nonce: 1, A sig, B sig Ở trên chuỗi, contract vẫn không đổi. Giả sử, offchain, A và B đã gửi đi gửi lại nhiều giao dịch: A: 0.3, B: 0.7, Nonce: 7, A sig, B sig Lúc này, A muốn kết thúc kênh, sẽ gửi số dư cuối cùng và các chữ ký cho contract. Lúc này sẽ bắt đầu Challenge Period (ví dụ 3 ngày). Onchain: A: 0.3, B: 0.7, Nonce: 7. Nếu trong 3 ngày, B không làm gì thì số tiền và trạng thái của contract sẽ theo những gì A gửi lên. Ngược lại, nếu B gửi lên 1 state với số Nonce lớn hơn (ví dụ = 9), thì contract sẽ theo state của B. Vấn đề được đưa ra là việc A và B phải quan sát thường xuyên xem đối phương có gửi state cũ lên không để có thể kịp thời ngăn chặn. Điều này được giải quyết bằng sự trợ giúp của WatchTower. Tóm lại, việc giao dịch sẽ chỉ tốn 2 lần onchain: Tạo channel Đóng channel và gửi tiền. Trên Bitcoin Vì trên UTXO không có trạng thái, nên sẽ khó khăn hơn để tạo 1 kênh thanh toán 2 chiều. Giải pháp được đưa ra là khi update kênh theo A, thì A sẽ nhận được Tx mà làm trạng thái cũ của B mất hiệu lực. UTXO Ta sẽ tạo UTXO mà có thể dùng theo 1 trong 2 cách (sử dụng IF trong Opcode): Relative time-lock: UTXO chứa số t. 1 Tx được kí hợp lệ có thể sử dụng UTXO này sau t blocks (hoặc nhiều hơn) sau khi nó được tạo ra. Hash lock: UTXO chứa một số X. Một Tx được kí hợp lệ có thể sử dụng UTXO này nếu có số x mà: SHA256(x) = X. (x được gọi là hash preimage của X). Ví dụ Giả sử A và B đưa BTC vào trong 2-2 Multisig UTXO AB, với A là 7BTC, B là 3BTC. A tạo số ngẫu nhiên x, và X = SHA256(x). B tạo số ngẫu nhiên y, và Y = SHA256(y). Sau đó, A đưa X cho B và ngược lại. A tạo Tx1 với input là UTXO AB, output là: 1: pay 7 -> A, 2: 3 -> B (7 ngày timelock) hoặc 3 -> A (với điều kiện đưa ra số y mà Y = SHA256(y)). B tạo Tx2 với input là UTXO AB, output là: 1: pay 3 -> B, 2: 7 -> A (7 ngày timelock) hoặc 7 -> B (với điều kiện đưa ra số x mà X = SHA256(x)). A có thể post Tx2, đợi 7 ngày và lấy 7 BTC về. Giờ nếu A gửi 1BTC cho B offchain. A tạo x’ và X’ = SHA256(x’). Sau đó đưa X’ cho B. A tạo Tx3 với input là UTXO AB, output là: 1: pay 6 -> A, 2: 4 -> B (7 ngày timelock) hoặc 4 -> A (với điều kiện đưa ra số y mà Y = SHA256(y)). B tạo Tx4 với input là UTXO AB, output là: 1: pay 4 -> B, 2: 6 -> A (7 ngày timelock) hoặc 6 -> B (với điều kiện đưa ra số x’ mà X’ = SHA256(x’)). Lúc này, A có thể post Tx3 và đợi 7 ngày. Nhưng nếu A post stale state là Tx2, B sẽ sử dụng x để lấy hết BTC. Do đó, A không thể gian lận và post lên trạng thái cũ. Multihop payments: Thanh toán nhiều lần A muốn thanh toán cho C qua trung gian không tin cậy là B (Vì A, C có channel với B). The lightning network Nhiều open payment channel 2 chiều. Khi A muốn tạo kênh với B thì chỉ cần tìm tuyến đường qua đồ thị với đỉnh là các trung gian. Kết luận Đây là cách tiếp cận đầu tiên để tăng tốc độ các Tx trong blockchain. Ở bài viết sau, mình sẽ giới thiệu một kĩ thuật khác giúp giải quyết vấn đề này.

Blockchain · 2023-08-18

Hệ thống vay DeFi

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Ở bài viết này, mình sẽ giới thiệu về hệ thống vay trong môi trường phi tập trung. Nhưng trước hết, ta sẽ đi tìm hiểu việc vay trong hệ thống tập trung sẽ như thế nào và chứa những rủi ro gì. Vay trong hệ thống tập trung Vì sao cần vay? Có các lý do chính như sau: Ví dụ, Bob cần vay ETH để mua một NFT trong game nhưng anh ấy không muốn bán tài sản của mình đi. Là chiến lược đầu tư, khi thế chấp ETH để nhận UNI, chờ tỉ giá UNI/ETH giảm, thì số UNI bỏ ra để mua 1ETH trả khoản vay sẽ ít hơn, từ đó nhận được UNI lãi. Trong hệ thống tập trung, người cho vay gửi tiền vào một Tổ chức tài chính tập trung. Người vay sẽ thế chấp 1 loại tài sản nào đó và sẽ được vay. Sau đó, người vay sẽ phải trả tiền lãi cho đến khi trả xong phần đã vay. Người cho vay sẽ được nhận 1 phần lãi đó. Tuy nhiên, nếu người vay không trả được khoản vay, Tổ chức tài chính tập trung sẽ mua lại tài sản thế chấp, và trả lại cho người vay phần còn thừa. Nếu giá trị tài sản thế chấp bị thay đổi và ít hơn tài sản vay, việc thanh lý tài sản thế chấp sẽ xảy ra. Tuy nhiên, với hệ thống tập trung, có các vấn đề được thấy rõ như sau: User cần tin tưởng Tổ chức, nhưng nếu bị hack hoặc bị xâm nhập trái phép, khả năng mất tiền rất cao. Tổ chức điều chỉnh tỉ lệ lãi,.. Người cho vay sẽ nhận ít tiền lãi hơn, vì phải chia 1 phần cho tổ chức. Do đó, việc tạo ra hệ thống vay phi tập trung không cần bên thứ 3 và áp dụng tính lập trình là mục tiêu được người dùng hướng đến. Các thuật ngữ Collateral : Tài sản thế chấp. Vai trò là đặt cọc để vay. Over-collateralization : Thế chấp vượt mức. Người vay phải đảm bảo giá trị thế chấp > giá trị vay. Under-collateralization : Thế chấp dưới mức. Xảy ra khi giá trị thế chấp < giá trị vay. Collateral Factor : Giá trị lớn nhất có thể vay, tính theo giá trị thế chấp. Ví dụ CF = 0.6, thế chấp có giá trị là 1000 DAI thì giá trị vay lớn nhất có thể là 0.6 * 1000 = 600 DAI. Với tài sản có độ biến động cao, CF thường thấp, ngược lại thì CF cao. Ví dụ: ETH, DAI: 83%, UNI: 75%, MKR: 73% Thanh lý : Nếu số tiền vay + lãi (gọi là nợ - Debt) > CF * Collateral (1) => Tài sản thế chấp sẽ được thanh lý đến khi (1) không còn xảy ra. Tỉ lệ thanh lý giúp người cho vay có thời gian thanh lý trước khi gặp rủi ro. Health : Health của 1 món nợ được tính bằng công thức sau: Nếu health < 1: Thanh lý sẽ được kích hoạt đến khi health >= 1. Liquidity : Thanh khoản. Là loại tài sản mà việc mua bán trên thị trường không thay đổi giá trị thị trường của nó. Nó cũng có khả năng chuyển thành tiền mặt. DeFi Lending Ý tưởng với OrderBook Dapp Lưu trữ các giao dịch trên một OrderBook. Người vay tạo giao dịch vay và chờ người cho vay fill. Bất lợi: Nhiều Txs, dẫn đến tính toán phức tạp Rủi ro: Không trả được nợ,.. Rút tiền phức tạp Liquidity Pool Over-collateralized lending: Compound and Aave Các LP (Liquidity Provider) cung cấp tài sản vào pool, và nhận những token tương ứng với tài sản mà họ đã cung cấp. Số lượng các token dựa vào Exchange Rate hiện tại. Exchange Rate sẽ được tính lại sau mỗi block. Với người vay, họ gửi tài sản vào Pool và nhận cTokens. Sau đó khi muốn vay (ETH), thì token của họ sẽ bị khoá như là Collateral, sau đó Compound sẽ gửi ETH cho họ. Tiền lãi tích luỹ khi vay của người vay sẽ làm tăng Exchange Rate ETH/token, từ đó giúp những người cho vay (giữ các token) được lợi ích khi token sẽ tăng giá. The Exchange Rate Giả sử với thị trường ETH: Supplying ETH: thêm vào UnderlyingBalance Borrowing ETH: thêm vào totalBorrowBalance Lãi phải trả: thêm lần lượt vào totalBorrowBalance Do đó, nếu tổng lượng vay càng nhiều, thì Exchange Rate sẽ càng tăng. Ngược lại nếu lượng UnderlyingBalance tăng thì lượng cTokenSupply tương ứng cũng sẽ tăng, từ đó dẫn đến ExchangeRate giảm. Interest Rate: Lãi xuất Lãi xuất được cập nhập một cách liên tục. Xác định bởi nhu cầu về tài sản với quy mô thị trường. Tỉ lệ sử dụng: Tỉ lệ này thuộc khoảng [0,1]. Tỉ lệ lãi: interestRate = BaseRate + U(ETH) x slope(ETH). Thanh lý Nếu health < 1, thì ai cũng có thể gọi hàm: liquidate(borrower, CollateralAsset, BorrowAsset, uint amount) Trong đó: borrower: address của người vay CollateralAsset: người thanh lý muốn token từ tài sản này (VD: cDAI) BorrowAsset: người thanh lý cung cấp tài sản này (ví dụ ETH) Hàm này chuyển ETH của người thanh lý ra thị trường ETH và cung cấp cho người thanh lý cDAI từ tài sản thế chấp của người dùng. Điều này tương đương với người thanh lý đang trả khoản nợ ETH cho người vay và nhận cDAI của người dùng. Flash loan Là khoản vay nhanh được thực hiện và hoàn trả trong 1 giao dịch. => zero risk cho người gửi, và không cần thế chấp. Các trường hợp được sử dụng Chênh lệch giá Người dùng Alice thấy chênh lệch giá USDC/DAI trong 2 pool, có thể dùng flash loan để kiếm lời. Ví dụ ở pool A có ExchangeRate là: 1.00, trong khi ở pool B là 1.01 thì Alice có thể flash loan 1 USDC, dùng để đổi được 1.01 DAI từ pool B. Sau đó dùng 1.00 DAI đổi lấy 1 USDC từ pool A, và trả flash loan. Do đó, Alice sẽ lời được 0.01 DAI. Hoán đổi tài sản thế chấp Nhận thấy việc thế chấp bằng ETH có thể bị sụt giá dẫn đến thanh lý, người dùng có thể đổi tài sản thế chấp thành USDC. Quá trình như sau: Nhận 1000 DAI flash loan Trả 1000 DAI để nhận 1 cETH Đổi 1 cETH lấy 3000 cUSDC Gửi 3000 cUSDC làm thế chấp để Mượn 1000 DAI Trả 1000 DAI flash loan Một số thông tin khác DAO: Decentralized orgs Là 1 DApp được triển khai onchain tại 1 địa chỉ cụ thể. Ai cũng có thể gửi tiền vào kho bạc của DAO và gửi đề xuất lên DAO. Đề xuất được thông qua và được các thành viên tham gia vote. Ví dụ: PleaseDAO: đầu tư vào NFTs Gitcoin: Tài trợ cho các dự án openSource. Giao thức Compound Là giao thức trên Ethereum, thiết lập thị trường tiền tệ, là những nhóm tài sản có lãi suất theo thuật toán, dựa và cung và cầu của tài sản đó. Các nhà cung cấp và người vay sẽ tương tác trực tiếp với giao thức, không cần phải thương lượng các điều khoản như kì hạn, lãi suất, hoặc tài sản thế chấp,.. Supplying Assets Tổng hợp nguồn cung từ các user. Khi user cung cấp assets, nó trở thành tài nguyên thay thế được, và mang lại tính thanh khoản cáo hơn khi cho vay trực tiếp. Từ đó người cho vay có thể rút tiền bất cứ lúc nào. Borrowing Assets Cho phép người dùng vay dễ dàng, sử dụng cTokens làm thế chấp. Người dùng không cần điều khoản đàm phán, ngày đáo hạn,.. Chi tiết về giao thức Compound, các bạn có thể xem ở đây Cross-chain AtomicSwap Các thuật ngữ cơ bản HTLC: hash time-locked contract Time-lock Khoá thời gian, khi đúng khoá thì cần 1 khoảng thời gian nhất định để pass, tức là hết thời gian thì mới mở được. Hash lock Yêu cầu key đúng + secret code. Sau khi nhập code thì sẽ hiển thị lên cho mọi người. Kịch bản Alice muốn Bitcoin, Bob muốn BCash. A và B quyết định đổi cho nhau. Các bước như sau: Alice tạo 2 Hashlock, yêu cầu cùng 1 SecretCode. Nhưng key thì 1 cái là key của A, 1 cái cần key của B. Alice đặt HashlockA và HashlockB vào lần lượt mailBoxA và mailBox B. Alice đưa BCash vào mailbox B, Bob đưa Bitcoin vào mailbox A. Sau đso, Alice đến mailboxA, nhập keyA và secretCode, nhận bitcoin. Đồng thời, sau khi Alice nhập, secretCode hiển thị cho mọi người nên Bob sẽ nhập theo + key vào mailBoxB, nhận được BCash. Trường hợp A không nhập SecreteCode hoặc cố ý chỉnh sai SecretCode ở 2 lock, thì time-lock sẽ được sử dụng: Độ dài của locktime của A phải lớn hơn của B (1 tuần >< 1 ngày) vì A biết secretCode. Do đó, khi B biết A lừa dối, B có thể quay lại mailBoxA và lấy tiền về ngay lập tức (vì lúc đó A vẫn đang đợi hết timelock để lấy được tiền). Ngược lại nếu locktime của A nhỏ hơn hoặc bằng B, thì A có thể đợi đến khi hết hạn, nhập code và lấy tiền (vì A có key của B lúc tạo lock). Kết luận Ở trên là toàn bộ hiểu biết của mình về hệ thống vay phi tập trung.

Blockchain · 2023-08-17

Sàn giao dịch phi tập trung

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Khái niệm Sàn giao dịch phi tập trung là loại ứng dụng phi tập trung, xây dựng với Smartcontract, cho phép users trao đổi ERC20 token hoặc NFT trực tiếp với các users khác. Lợi ích Không giữ tiền: Không có bên thứ 3 giữ tiền trung gian các giao dịch Chống kiểm duyệt: Ai gửi Tx đều có thể sử dụng Permissionless: có thể hỗ trợ bất kì asset nào. Thuận tiện: Không phải gửi tài sản trên chuỗi vào một sàn giao dịch Tính lập trình: Thanh khoản có thể xem bởi các smartcontract Tính nguyên tử: Orderbook là sổ lệnh, bao gồm các lệnh bạn và mua tài sản theo từng mức giá nhất định. Cơ chế khớp lệnh này khiến lệnh của người dùng được thực thi khi giá của sổ lệnh khớp với giá người dùng mua hoặc bán. Các loại DEX On-chain orderbook Market makers đặt các order lên chuỗi, người dùng sẽ điền các order này trực tiếp trên chuỗi nếu họ muốn giao dịch. Tuy nhiên, cách này sẽ gây tốn gas rất nhiều. Off-chain orderbook Market makers kí các orders ngoài chuỗi. Người dùng sẽ điền các order này rồi submit nó lên chuỗi. Cách này sẽ không tận dụng khả năng lập trình và thanh khoản sẽ không hiển thị với smartcontract. Dutch auctions User đặt các order lên chuỗi, giá sẽ từ từ điều chỉnh để thu hút. Market maker sẽ điền order đó khi họ thích mức giá đó. Vấn đề của cách này là điều chỉnh giá chậm Automated market maker Market markers sẽ đưa các tài sản vào trong 1 pool. Người dùng sẽ trade với pool đó mới mức giá được xác định bởi thuật toán. Lợi ích: Tiết kiệm gas Dễ sử dụng, … Cách Automated market maker (AMM) hoạt động Giả sử 1 AMM có 2 loại tài sản, 1 là X (risky, ví dụ: ETH), 2 là Y (stable, ví dụ DAI). AMM lưu trữ x đồng X và y đồng Y. AMM đề nghị mua hoặc bán tài sản X ở một giá trị p nào đó. Giả sử, ta muốn duy trì tài sản X và Y trong pool với tỉ lệ $a/b$. Giả sử là $50/50$ Vì p là giá trị của X nên ta thấy: $p.x = y \iff p = y / x.$ Khi đó, nếu ai đó bán lượng ETH (X) để lấy DAI (Y) thì x sẽ tăng và y giảm xuống. Dó đó giá trị p sẽ giảm đi. Điều này tương đương với x, y tỉ lệ nghịch với nhau. Gọi $x * y = k$ thì k được gọi là hằng số dự trữ. Ví dụ: Nếu pool có 10 ETH, 1000 DAI. Giá của 1 ETH = 100 DAI. Hằng số dự trữ: $k = x * y = 10 * 1000 = 10000$. 1) Giả sử user muốn đổi DAI lấy ETH. Muốn đổi 500 DAI + 0.3% phí để đổi lấy ETH. Lúc này: y’ = 500 + 1500 = 1500. => x’ = 10000 / 1500 = 6.66 ETH. Lúc đó, user này sẽ nhận: 10 - 6.66 = 3.33 ETH $\rightarrow$ Giá p của 1 ETH = 150 DAI (Tăng giá). 1) Giả sử user muốn đổi ETH lấy DAI. ĐỔi 6ETH + 0.3% lấy DAI. Lúc này: x’ = 10 + 6 = 16 => y’ - 10000/ 16 = 625. User nhận 1000 - 625 = 375 DAI. Giá p 1ETH = 62.5 DAI, giảm 37.5 so với ban đầu. Liquidity Provider Là những người cung cấp thanh khoản cho pool, nhận lại được các Liquidity Token, tương đương với thanh khoản mà họ cung cấp. Khi người dùng đổi các tài sản trong pool, phần trăm phí sẽ được trả cho các LP này dựa vào số thanh khoản mà họ cung cấp. Độ thanh khoản của pool được tính bằng công thức: L = sqrt(k) = sqrt(x * y). Những điểm cần phát triển của AMM Phí gas Trượt giá: Biến động giá bởi các giao dịch từ người dùng Chênh lệch giá Hiệu quả sử dụng vốn Concentrated Liquidity Để tăng hiệu quả sử dụng vốn, các LP có thể gửi thanh khoản ở mức giá trong khoảng cụ thể. Ví dụ như ở hình ảnh trên, là chuyển đường cong xy = k xuống dưới và sang trái. Lí do là vì giá trị p của thanh khoản sẽ chỉ ở trong 1 khoảng nhất định (Ví dụ DAI chỉ ở trong khoảng từ (0.95 ~ 1.05) USD). Do đó, khi PL cung cấp thanh khoản ở khoảng từ (0, ∞) thì hiệu quả sử dụng vốn của họ sẽ không được cao. Do đó, ở mỗi số sàn giao dịch, việc thanh khoản tập trung trông 1 khoảng hữu hạn là 1 vị trí. Vị trí này cần duy trì đủ dữ trữ để hỗ trợ giao dịch trong phạm vi của nó. Từ đó khiến nó hoạt động như một constant product pool với dự trữ lớn hơn trong khoảng đó. Từ đó việc sử dụng vốn sẽ có hiệu quả hơn. Kết luận Về cách các loại sàn hoạt động, mọi người có thể xem ở các whitePaper, ví dụ với Uniswap .

Blockchain · 2023-08-15

Stablecoins

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Stable coin là 1 loại tiền điện tử được tạo để giao dịch với một giá trị không đổi. Mục đích sinh ra Stablecoin là tích hợp tiền tệ trên thế giới thật vào các ứng dụng trên chuỗi và cho phép những người không thể có USD nắm giữ và giao dịch 1 tài sản tương đương. Custodial Stablecoin: Stablecoin kí gửi Custodian giữ kho bạc trong 1 ngân hàng truyền thống, mọi giao dịch đều thông qua nó. Ngoài ra, nó có quyền mạnh mẽ như kiểm duyệt khác hàng rút tiền hoặc xoá số dư người dùng. Điều này sẽ nguy hiểm nếu chẳng may bị hack hoặc nhầm lẫn và không đảm bảo sự phi tập trung. Do đó, cách này không được ưu tiên và sử dụng ở thực tế. Synthetic Mục tiêu là xây dựng 1 loại non-custodial stablecoin. Tuy nhiên, có một vấn đề là ETH thường xuyên dao động, không ổn định so với USD. Maker DAO: xây dựhng một stablecoin từ tài sản không ổn định. Hệ thống MakerDAO: DAI: stablecoin (giá: 0.99 ~ 1.01 USD) MKR: ai cũng có thể mua để kiếm lãi. Sử dụng để quản trị, ổn định giá DAI trong trường hợp khẩn cấp. Đúc DAI Giả sử: A muốn trả B bằng DAI nhưng A chỉ có 1 ETH. A sẽ tạo 1 vault trên MakerDAO contract: 1 wallet: tài sản mà A kiểm soát. 1 vault: tài sản mà A khoá để vay DAI. Ta có: Ban đầu, A có: 1ETH, 0DAI trong wallet, 0ETH, 0DAI trong vault. Khi A khoá 1 ETH vào vault: trong wallet sẽ không còn ETH, trong vault có 1ETH Việc khoá ETH xem như một cách thế chấp để vay DAI. Vì số lượng thế chấp = 130% số lượng tối đa có thể vay, nên khi A thế chấp 1 ETH (~3000USD) thì chỉ có thể vay tối đa 2300 DAI. Do đó, trong wallet A có 2300DAI, còn vault: 1ETH, -2300DAI. A trả cho B bằng DAI, và có thể trả nợ cho vault để lấy lại 1 ETH. Stabilization A khi thế chấp ETH và vay DAI, phải trả lãi: Phí ổn định. Hầu hết các phí đều đưa cho DAI holders (thông qua DSR), một số còn lại đưa cho MKR holders. The DAI saving rate (DSR) Bất kì ai giữ DAI có thể khoá DAI của mình trong MakerDAO contract. DSR là tỉ lệ lãi từ DAI đã khoá ở trên contract. Users có thể rút DAI ra từ contract bất cứ lúc nào. Cơ chế ổn định: DAI có giá trị < 1$ ⇒ tăng phí ổn định và DSR: Người đúc DAI được khuyến khích hoàn trả món nợ đã vay sớm vì lãi đang tăng Khuyến khích DAI holders gửi nhiều DAI vào contract Từ đó giúp giảm nguồnn cùng DAI, giúp DAI tăng giá DAI có giá trị > 1$ ⇒ giảm phí ổn định và DSR. Thanh toán Nếu vault debt vượt quá 130% (do lãi), thì tài sản thế chấp sẽ được bán đấu giá. (Tiền lãi - phí) sẽ được trả nợ vault cho A đến khi đạt dưới 130%. NFTs NFTs là: Quyền sở hữu token của 1 tài sản kĩ thuật số (như Digital Artwork, vitual games item,…). Không thể có NFT nào giống nhau, nên không thể trao đổi lẫn nhau. Được xác định bởi lịch sử, mức độ tiện ích, tầm quan trọng,… NFTs được quản lý dưới blockchain vì: Blockchain đảm bảo quyền sở hữu dài hạn cho đến khi bán. Cung cấp một hồ sơ đáng tin cậy về xuất xứ (chống giả mạo). Sở hữu tài sản kĩ thuật số NFTs hoạt động như một chứng thư pháp lý: Có thể chuyển quyền sở hữu từ bên này sang bên khác Quyền sỏ hữu thể hiện tình trạng sở hữu tài sản, cấp quyền hợp pháp,… Nhận NFTs như thế nào Có 2 cách chính là tìm người sở hữu và mua từ học, hoặc lên thị trường và mua. Thị trường NFT Được xây dựng như một tập các smartcontract, thành một hệ thống tài sản và trao đổi. NFT mang lại sự sở hữu đích thực trên Internet, kích hoạt thương mại kĩ thuật số,… Ví dụ: một số NFT đặc biệt mang lại cho người dùng sự truy cập vào một số IP, trang trên Internet. NFT cost issue Đa phần các NFT đều có giá cao, do đó muốn sở hữu thì có thể thuê hoặc tiết kiệm. Sẽ khó bắt đầu kinh doanh NFT nếu không có tiền mặt hoặc nguồn cung cấp đủ lớn. Một số dịch vụ dựa trên NFTs như: Gameing guild (các item trong game: NFTs), EveryRealm (Bất động sản ảo), Credit Provider,…

Blockchain · 2023-07-24

Solidity và State Trie

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Ở bài viết này, mình sẽ giới thiệu về Solidity và World State Trie Solidity Solidity là ngôn ngữ lập trình cho Blockchain Ethereum, là ngôn ngữ hướng đối tượng, cấp cao để triển khai các smartcontracts. Smartcontract là chương trình chi phối các hành vi của Account trong Ethereum State. Account contract được tạo ra khi chạy một smartcontract. Mọi người có thể đọc account contract state ở trong storage array, nên không bao giờ được lưu trữ các bí mật trong contract. Một số dạng biến của Solidity như: uint256, address(byte 32), bool,… Các loại tham chiếu là mảng, struct, string, map,… Khi một giao dịch đi từ A ⇾ B ⇾ C ⇾ D thì tại D, msg.sender là C, nhưng tx.origin là A. ERC20 là API tiêu chuẩn cho fungible token, cung cấp các chức năng cơ bản để chuyển token hoặc cho phép token được sử dụng bởi bên thứ 3. Các kiểu lưu trữ: Stack variables: Rẻ để sử dụng, phù hợp với mọi loại dữ liệu (không qua 32 bytes) Calldata: Là 1 mảng byte chỉ đọc, tốn gas Memory: 1 byte mảng, rẻ, nhưng chi phí tăng theo cấp số nhân, lưu được dữ liệu > 32 bytes Storage: Đắt, mappings và các biến state lưu trong này. Event logs: rẻ, không cần truy cập đến contract. Ở trên là một số hiểu biết của mình về solidity, về mặt coding, mọi người nên xem ở đây. State trie (Ethereum state trie) Hình ảnh đây là cấu trúc được tạo bởi các loại State trong Ethereum: (ở góc phải dưới hình ảnh) Có 3 loại state chính là World state, Transaction, và Transaction Receipt. World State Trie World State Trie Là mapping giữa địa chỉ và Account State. Nó được update bởi các Tx, và lưu trữ mọi thông tin về accounts và có thể lấy được qua các truy vấn. Trong World State Trie có Account Storage Trie, nơi các dữ liệu liên kết với account được lưu trữ. Nó chỉ liên quan đến các contract account và mọi dữ liệu được ánh xạ giữa các số nguyên 32 byte. Account State là các thông tin về một Ethereum account, như balance, nonce, storage Root, codehash,… và là lá của World State Trie. Transaction Trie Transaction Trie lưu trữ các Tx trong Ethereum. Khi các Tx lưu trữ trong block, nó không thể bị thay đổi. Nó được xây dựng theo cấu trúc Modified Merkel Patricia Trie, và chỉ có node root mới được đưa vào trong block. Transaction Receipt Trie(Receipt Trie) Transaction Receipt Trie lưu trữ đầu ra của các Txs. Đầu ra là kết quả của một Tx mà được chạy thành công, bao gồm H(Txs), block number, gas Used, địa chỉ của contract. Ví dụ cấu trúc của World State (một cách đơn giản) Để đơn giản, ta giả sử các node lá của World State Trie chỉ bao gồm địa chỉ là số dư theo cặp Key - Value. Các loại thông tin: Leaf Node: node lá của cây, chứa các trạng thái của 1 tài khoản có địa chỉ là Key Branch Node: gồm 16 ô, là các tiền tố của Key. Extension Node: node chỉ có 1 child Nibble: Là phần chung trong Key, 1 Nibble = 4 bits, lưu trong keyend hoặc shared nibble. Prefixes: 0: extension node có số chẵn Nibble 1: extension node có số lẻ Niblle 2: leaf node, có số chẵn Nibble 3: leaf node, có số lẻ Nibble. Minh Hoạ: World State Trie với 4 cặp Key - Value như sau: a711355: 45 ETH a77d337: 1 WEI a7f9365: 1.1 ETH a77d397: 0.12 ETH Kêt luận Ở trên là một số khái niệm sơ bộ về Solidity và cấu trúc của Ethereum, cụ thể về các State Trie.

Blockchain · 2023-07-24

Proof Of Stake

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Ở bài viết này, mình sẽ giới thiệu một cơ chế đồng thuận đang được sử dụng rất nhiều trong các blockchain hiện nay, đó là Proof of Stake. Accountable Safety Một giao thức với resilence là n/3 khi giao thức đó an toàn nếu nó có ít hơn n/3 Adverserial node (Ví dụ streamlet). Một giao thức với Accountable Safety resilence n/3 là giao thức: An toàn nếu ít hơn Adverserial node. Nếu vi phạm safety, thì những người giám sát (các node không phải người được chọn để đề xuất khối) có thể xác định rõ các node vi phạm. Không có cáo buộc sai với các node trung thực. Finality và Dynamic availability Gọi một giao thức là finality nếu nó duy trì safety trong thời gian không đồng bộ (trước GST). Ở các giao thức này, Tx được finalize nhanh hơn confirm trong bitcoin (60 phút). Gọi một giao thức là Dynamic availability nếu giao thức đó có thể tiếp tục confirm các giao dịch ngay cả khi nhiều node offline. Không có giao thức SMR nào đảm bảo cung cấp cả 2. Do đó, một cách giải quyết là sử dụng Nested chains. Nested chains Available chain được xác định bởi giao thức Π_ava, thoả mãn Dynamic availability (VD: Nakamoto consensus). Finalized chain được xác định bởi giao thức checkpoint $Π_{fin}$ thoả mãn security dưới mạng đồng bộ 1 phần. Chuỗi confirm bởi Π_ava là available chain. $Π_{fin}$ kiểm tra các block trong availbale chain. Tiền tố của checkpoint cuối cùng tạo thành finalized chain. Tương đương với Finalized chain là prefix của available. Chuỗi này safe dưới mạng bất đồng bộ Các block của available chain luôn extend từ điểm checkpoint cuối cùng. Minh hoạ: Proof of Stake Tổng quan Trong giao thức Pos, các nodes khoá (Stake) tiền của họ trong giao thức để đủ điều kiện tham gia consensus. Càng nhiều coin được stake bởi 1 node thì khả năng cao node đó được chọn làm validator. Vì thuật toán lựa chọn validator là giả ngẫu nhiên. Nếu node bị bắt quả tang thực hiện 1 hành động bất lợi (xác thực giao dịch sai) thì node đó sẽ bị burn số tiền đã stake và không thể tham gia vào quá trình đề xuất khối tiếp theo. (Slashing). Do đó, trong PoS, nodes sẽ có trách nhiệm trong cách hành động của mình. PoS giúp thay đổi cơ chế block được verify. Ngoài ra, để trở thành validator, các node phải có điều kiện (ví dụ: có ít nhất 32 ETH,..), sau khi đóng 1 khối, khối đó sẽ được các validator khác validate theo nhiều method khác nhau tuỳ vào blockchain. Cụ thể với Ethereum 2.0 Chọn Validator và Block Proposer Để thành một validator, phải gửi ít nhất 32 ETH vào contract và chạy 3 phần mềm riêng biệt (sẽ giới thiệu ở sau) và tham gia hàng đợi. Thời gian của blocks chia thành các slot: 12s, epoch: 32 slot. Sau khi được active, validator đó sẽ tham ra vào quá trình phê duyệt. 1 validator ngẫu nhiên sẽ được chọn để xác thực giao dịch và đề xuất khối ở mỗi slot (Block proposer). Số còn lại sẽ làm giám sát để phê duyệt và kiểm tra xem validator đó có gian lận không. Chọn Block Proposer quá trình giả ngẫu nhiên gồm nhiều yêu tố như staking age, số tiền stake,… Ở đây, mình sẽ giới thiệu 2 phương pháp lựa chọn là: Randomize block selection: lựa chọn bằng cách tìm kiếm nodes có sự kết hợp của hash value thấp nhất và stake cao nhất. Vì size của các stakes là công khai nên có thể dự đoán được. Coin Age Selection: là phương thức chọn các nodes dựa vào khoảng thời gian stake. Coin Age được tính bằng: số ngày đặt cược x số lượng coin. Khi một node forge một block, coin age của nó được cài về 0. Quy trình xác thực Khi một user tạo Tx và submit lên Ethereum, nó sẽ được kiểm tra tính hợp lệ (Ví dụ đảm bảo số tiền, key đúng,…) sau đó được đưa đến mempool và phát tán nó đến các node khác. Một node được chọn làm Block Proposer để đề xuất khối ở slot này, có trách nhiệm đóng và phát tán block vào chuỗi và cập nhập trạng thái. Nodes chạy 3 phần mềm: Execution client: gộp các Txs từ mempool thành “execution payload” và chạy nó ở local để tạo ra sự thay đổi trạng thái. Thông tin này được chuyển đến consensus client Consensus client: đóng gói payload thành 1 phần của “beacon block” (gồm payload, slashing,…) cho phép mạng thống nhất trình tự về các khối. Validator client: Các node nhận được beacon block qua tầng gossip network. Sau đó chuyển đến Execution client của nó để chạy lại, nhằm chắc chắn trạng thái là đúng. Sau đóm Validator client sẽ chứng thực khối đó hợp lệ và là khối tiếp theo trong góc nhìn của chuỗi (available chain). Khối cũng được thêm vào cơ sở dữ liệu local của các node. Finality Như đã nói ở trên, các block của available chain luôn extend từ điểm checkpoint cuối cùng. Checkpoint là các block đầu tiên ở mỗi epoch. Các validators có thể vote cho cặp checkpoint (1 epoch), nếu ít nhất 2/3 vote cho nó, cặp checkpoint này sẽ được cập nhập, và các block nằm giữa sẽ được cập nhập thành finalized chain. Nếu chuỗi không thể finalized trong nhiều hơn 4 epoch liên tục, stake ETH từ các validator chống lại đa số sẽ bị biến mất, cho phép đa số chiếm hơn 2/3 và finalized chuỗi. Lời kết Ở trên là cách hoạt động cơ bản của POS. Mọi người có thể xem thêm các thông tin về POS trong Ethereum tại đây.

Blockchain · 2023-07-23

Cơ chế Ethereum

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Mặc dù bitcoin được ra đời từ rất sớm và được sử dụng cho đến hiện tại, nó vẫn chứa nhiều nhược điểm. Phần chính là các ScriptPk của UTXO không thể thực hiện các quy tắc phức tạp về tài sản. Ví dụ khi muốn đưa ra giới hạn lượng BTC sử dụng trong 1 ngày là 2BTC, không thể làm với UTXO Script được. Do đó, Ethereum ra đời với nhiều ưu điểm vượt trội So sánh chung Bitcoin như một máy chuyển trạng thái. Bitcoin rule: S x I ⇾ S, với tập S là các trạng thái, I là tập tất cả các input. Còn với Ethereum, hàm chuyển trạng thái của nó sẽ phong phú hơn nhiều, và mỗi lần chuyển đổi thì sẽ thực hiện toàn bộ chương trình. Ethereum hỗ trợ các DApp, với Program code được lưu trữ trên blockchain, khi chạy cũng sẽ thay đổi các trạng thái. Các block thì sẽ có khoảng 150 Tx, và các Block Proposer sẽ nhận Tx fee cho block và các phần thưởng khác khi tạo khối thành công. Ngoài ra, ta đã biết rằng khi các block được proposer trong consensus layer (các beacon block, nên còn được gọi là beacon chain), các node gửi các Tx lên cho execution client hay còn gọi là compute layer để cập nhập các trạng thái (update world state). Compute layer World state: tập hợp các tài khoản được xác định bởi các địa chỉ 32 byte (Các thông tin như địa chỉ, số dư,..) Có 2 loại tài khoản: Owned account: Điều khiển bởi các cặp (Pk, Sk), hay là tài khoản của người dùng. Contracts: Điều khiển bởi code, được tạo lúc tài khoản được tạo, không thể thay đổi. Các dữ liệu cần thiết với mỗi account: Account Data Owned Contracts address(tính) H(Pk) H(CreatorAdd, CreatorNonce) storage root Không StorageRoot code không CodeHash balance balance balance nonce nonce nonce Trong đó, nonce là số Tx mà acount đã thực hành, tính bằng (#Tx sent) + (#accounts created). Số nonce được dùng để chống replay và khi tạo mới thì luôn bằng 0 (với contract). Các contract có thể bị ghi đè code, nhưng chỉ khi contract cũ đã SELFDESTRUCT. Mỗi contract có 1 mảng lưu trữ liên quan gồm 2^256 phần tử, mỗi phần tử là 32 bytes. Và storage root là Merkle Patricia hash của mảng. Chuyển trạng thái Tx Được kí bởi người tạo. To: nếu = 0 là tạo account mới, code = (init, body). Còn lại là 32-bytes địa chỉ và data (những thứ mà contract gọi và các đối số). From: Địa chỉ khởi tạo và chữ kí vào Tx Value: số Ethereum được gửi. Tx fees: gasLimit, maxFee, maxPriorityFee (Sẽ nói rõ hơn ở phần sau). Nonce: Khớp với nonce hiện tại của người gửi, tránh việc replay Tx. Chain-id: đảm bảo giao dịch gửi đúng chuỗi (không thể dùng giao dịch testnet lên mainnet). Các loại Tx owned ⇾ owned: chuyển ETH giữa các user owned ⇾ contract: gọi contract với ETH & data Messages Là các Tx ảo được contract tạo ra, nó không có Signature (vì contract không có). Có 2 loại là: contract ⇾ onwed: contract gửi tiền cho user contract ⇾ contract: contract gọi contract khác. Ethereum block Khác với Block của Bitcoin, Block Header của Ethereum có nhiều loại dữ liệu hơn, một số chính như: Consensus data: các dữ liệu như Proposer Id, Previous hash, vote,… Address: Nơi mà gas fee được chuyển đến World state root: Merkle Patricia Tree Hash của tất cả các tài khoản Tx root: Merkle Tree Hash của Tx Tx receipt root: Merkle Hash của các log message Gas used: Sử dụng để điều chỉnh giá gas (ở phần sau). EVM mechanics EVM là môi trường thực thi (execution). Các contract được viết bằng solidity, sau đó sẽ được compile thành EVM bytecode và được các validator sử dụng để chạy các contract. EVM hoạt động như một Stack Machine với lệnh JUMP (Các program sẽ bị huỷ nếu quá stack, proposer giữ lại gas). Gas Gas được xem như là nguyên liệu của Ethereum, là khoản phí cần trả để thực hiện các giao dịch hay hoạt động tương tác với smartcontract. Mọi chỉ thị đều tốn gas, giúp ngăn việc gửi Tx có nhiều bước (tốn nhiều tiền hơn). Các Proposer có thể chọn các Tx từ mempool có phí gas cao để tối đa hoá thu nhập. Gas calculation Mỗi block có: baseFee: gasPrice nhỏ nhất cho tất cả Tx trong block. BaseFee dựa vào tổng số gas ở block trước (Gas used ở header), nếu gasUsed là giới hạn (30M) thì baseFee tăng 12.5%, nếu block trước trống thì giảm 12.5%. Còn lại thì giữ nguyên. gasLimit: tổng gas cho phép với Tx maxFee: giá gas tối đa cho phép maxPriorityFee: ‘tips’ tối đa cho Proposer. GasPrice = min(maxFee, baseFee + maxPriorityFee) MaxTxFee = gasLimit x gasPice Cụ thể nếu gasPrice < baseFee: dừng nếu MaxTxFee > sender.balance: dừng trừ MaxTxFee khỏi sender.balance Đặt Gas = gasLimit Chạy Tx, trừ gas từ Gas với mỗi Tx. Nếu Gas < 0 thì dừng, Proposer giữ gasLimit * gasPrice. Xong xuôi, trả lại Gas x gasPrice cho sender gasUsed = gasLimit - Gas. BURN gasUsed x baseFee và gửi gasUsed x (GasPrice - baseFee) cho block proposer. ETH bị BURN vì giúp giảm lạm phát, tăng tính khan hiếm, có lợi cho nhà đầu tư, chặn các proposer tạo ra các Tx giả, không khuyến khích các thoả thuận ngoài chuỗi. Kết luận Ở trên là toàn bộ hiểu biết của mình về cơ chế Ethereum.

Blockchain · 2023-07-23

Đồng thuận trên mạng

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Ở bài viết trước, ta đã biết rằng các node sẽ tham gia vào giao thức có thể là Adversary và có thể gây hại cho blockchain. Vậy làm cách nào để chọn các node hợp lý để tham gia vào consensus. Bitcoin Mining Bitcoin chọn các nodes tham gia vào giao thức bằng các sử dụng POW, giải bài toán tìm số nonce (xem chi tiết tại đây). Bitcoin sử dụng Nakamoto consensus: Quy tắc đề xuất: ở bất kì thời điểm nào, mỗi miner trung thực mở rộng chuỗi nặng nhất (với độ khó cao nhất). Quy tắc confirmation: Miner confirm 1 block (với tiền tố của nó) mà ở độ sâu $k$ trong chuỗi nó nhìn được. Ví dụ trong thực tế: $k$ = 6. Miner và client chấp nhận các Tx ở block cuối cùng được confirm và tiền tố của nó như là log. Leader được chọn bởi POW. So sánh giữa Bitcoin và Streamlet: Streamlet thì không dynamic available: Nó sẽ không đảm bảo liveness nếu $n/3$ hoặc hơn các nodes offline. Bitcoin thì dynamic available: tiếp tục confirm Tx khi miningpower offline. Consensus ở Internet Các nodes tham gia mở, tức là các adversary có thể tạo nhiều node và người tham gia trung thực có thể online hoặc offline và đi tuỳ ý. Do đó, mục tiêu đặt ra là phải hạn chế sự tham gia của Adversary, đồng thời duy trì dynamic available của giao thức. Security Bitcoin đảm bảo an toàn dưới mạng đồng bộ, với tỉ lệ mining power do Adversary kiểm soát $\beta < 1/2$ Nakamoto’s Private Attack: $\beta$ ≥ 1/2 Khi adversay đào block mới, nhưng không công bố. Các miner trung thực tiếp tục đào mà không biết về các block ẩn này. Khi adversary công bố chuỗi đó (đã tạo đủ block), chuỗi đó trở thành chuỗi dài hơn chuỗi mà miners trung thực đào được (vì $\beta \ge 1/2$), các block đào bởi các miner trung thực sẽ bị bỏ. Forking Vì Network delay, các honest blocks ở cùng 1 độ cao. Do đó, tỉ lệ phát triển các khối honest sẽ chậm hơn so với $1 - \beta$. Do đó, Adversary sẽ thành công nếu $\beta \ge (1 - \beta) / 2$ (Trường hợp chỉ có 2 chuỗi fork). Security Nếu $\beta < 1/2$, tồn tại tỉ lệ Mining đủ nhỏ $\lambda(\Delta,\beta) = \lambda A + \lambda H$ mà Bitcoin thoả mãn security với tỉ lệ lỗi chấp nhận là $𝑒^{−\Omega(𝑘)}$ dưới mạng đồng bộ. Đây là xác xuất lỗi với comfirmation. Đây chính là lý do sau 10 phút mới tạo ra khối mới chứ không phải là 1 giây. Chứng minh Nhận thấy, với các khối trung thực được tạo, vẫn có thể tạo ra fork vì khối sau được tạo ra quá gần khối trước ($< \Delta$). Lúc này, khối tạo sau được gọi là Tailgater. Ngược lại, nếu khối được tạo ở thời điểm t, và không tồn tại khối nào được tạo trong khoảng thời gian từ $t - \Delta$ đến t, thì khối đó được gọi là Non-Tailgater. Các khối Non-Tailgater thì có độ cao riêng biệt nhau. Giờ, ta cần tìm tỉ lệ các khối trung thực là Tailgater hoặc Non-Tailgater. Xem thời gian tạo các khối là biến ngẫu nhiên Poisson, thì khoảng thời gian T giữa 2 khối tuân theo phân bố mũ. Gọi mining rate là $\lambda$ (1/ minutes). Với Bitcoin $\lambda = 1/10$. Theo phân bố mũ, xác suất để T lớn hơn s bất kì là: $P[T > s] = 𝑒^{-λs}$. Suy ra, nếu $s = \Delta$ thì tỉ lệ honest block tạo ra là Non-Tailgater là $g = P[T > \delta] = 𝑒^{-\lambda \delta}$, Tailgater là $1 - g$. Ta thấy, các Non-tailgater block tăng với tỉ lệ: $g*λ$, các block này có height khác nhau, vì thế chuỗi dài nhất cũng tăng ít nhất với tỉ lệ này. Điều này thoả mãn với liveness. Với Safety, ta cần thêm các khái niệm sau: Block B được đào ở thời gian t, nếu không có honest block nào khác được đào từ $t−\Delta$ đến $t+\Delta$ thì B gọi là loner. Do đó, loner là block duy nhất ở độ cao đó. Để vi phạm safety, cần phải có hai chuỗi khác nhau hơn $k$ khối, cả hai đều được thông qua bởi các node trung thực. Điều này tương đương với các Adversary phải khai thác các khối nhanh hơn các khối loner được tạo ra. Gọi tỉ lệ mine của Adversary là $\beta$. Tỉ lệ mine loner là $g\times g \times \lambda$. Do đó, giao thức Nakamoto đảm bảo security nếu $g\times g \times \lambda > \beta$. Kêt luận Ở trên là sơ lược về giao thức Nakamoto. Nếu mọi người muốn xem chi tiết về cách chứng minh, hãy truy cập vào đây.

Blockchain · 2023-07-22

Cơ bản về đồng thuận

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Ở bài viết này, chúng ta sẽ tìm hiểu về cách Bitcoin chống lại việc những nodes không trung thực tấn công vào mạng lưới. Adversary là gì ? Những nodes không trung thực (Adversary) là những nodes gây hại, chúng có mục đích khiến Blockchain không còn minh bạch và nhẩt quán để dễ dàng thêm vào những giao dịch sai mà có lợi cho chúng. Tác hại của Adversary Có thể gây: Lỗi crash: Nếu các nodes này không gửi và nhận các msg (message) Lỗi bỏ sót: Nếu các nodes này chọn hoặc bỏ qua các msg Lỗi Byzantine: Các node sai có thể đi lệch khỏi giao thức. Có 2 loại adversary Static: phá huỷ node mà nó chọn trước khi bắt đầu giao thức. Adaptive: có thể phá huỷ các node khi giao thức xảy ra. Giới hạn sức mạnh của adversary là số node: $f$. Ví dụ: $f < n/2$, $f < n/3$. Các nodes giao tiếp với nhau Các nodes gửi các tin nhắn (message) cho nhau trong giao thức. Giả sử một node adversary đang điều khiển việc gửi tin nhắn: Trong một mạng đồng bộ: Adversary phải chuyển tin nhắn bất kì trong thời gian $\Delta$ giây ($\Delta$ đã biết). Trong mạng không đồng bộ: Adversary có thể hoãn msg trong 1 khoảng thời gian hữu hạn, nhưng cuối cùng vẫn phải chuyển. Trong mạng đồng bộ 1 phần: tồn tại 1 sự kiện gọi là GST mà: Một msg gửi bởi 1 honest node ở thời gian t sẽ đến với người nhận trong khoảng thời gian: $\Delta + Max(t, GST)$. Điều này tương đương với mạng sẽ không đồng bộ cho tới GST, sau đó sẽ đồng bộ State Machine Replication (SMR) Là phương pháp chung để triển khai dịch vụ chịu lỗi bằng việc sao chép máy chủ và điều phối tương tác của máy client với bản sao đó. Nó cung cấp framework để hiểu và thiết kết giao thức quản lý sao chép. SMR gồm 2 phần: Replicas: Nhận Tx, chạy giao thức SMR và xác định log. Các Log(Ledger) là chuỗi Tx thứ tự tuyến tính. Client: Giao tiếp với replicas để nhận log (ví dụ: wallet). Các wallet không chạy giao thức SMR và cũng không giao tiếp với nhau. Nó hỏi các replicas về các log và chọn kết quả được nhiều replicas gửi về nhất. Bảo mật cho SMR Gọi $A ≼ B$ khi $A$ là tiền tố của $B$. Ví dụ: $A = Tx_1Tx_2Tx_3$, $B = Tx_1Tx_2Tx_3Tx_5Tx_6$ thì A là tiền tố của B. Gọi $LOG(i, t)$ là log đưa ra bởi client $i$ ở thời điểm $t$. Một giao thức SMR là an toàn nếu thoả mãn: Safety: Với client $i$ và $j$, ở 2 thời gian $t$ và $s$: $LOG(i, t) ≼ LOG(j, s)$ hoặc $LOG(j, s) ≼ LOG(i, t)$ hoặc cả 2, điều này giúp cho không thể xảy ra Double Spent Liveness: với Tx là input của 1 honest replica ở thời điểm $t$, với mọi i ở thời điểm $s ≥ t$ thì: $Tx \in LOG(i, s)$. Giao thức Blockchain Các Txs được đóng thành các block để tăng thông lượng. Gọi $CH(i, t)$ là chuỗi được accept bởi client $i$ tại thời gian $t$. Giao thức blockchain đảm bảo an toàn nếu thoả mãn: Safety: Với client $i$ và $j$, ở 2 thời gian $t$ và $s$: $CH(i, t) ≼ CH(j, s)$ hoặc $CH(j, s) ≼ CH(i, t)$ hoặc cả 2 Liveness: với Tx là input của 1 honest replica ở thời điểm $t$, với mọi $i$ ở thời điểm $s ≥ t$ thì: $Tx \in CH(i, s)$. Mong muốn giao thức phải đảm bảo an toàn dưới môi trường bán đồng bộ. Theo DLS(1988), nếu $f ≥ n/3$ thì giao thức SMR không thể đảm bảo an toàn. Bây giờ với $f < n/3$, ta sẽ chứng minh là giao thức này an toàn. Chứng minh giao thức blockchain Thời gian chia thành các epoch, mỗi epoch là $2\Delta$ giây. Có $n$ replicas cố định, mỗi epoch e được chỉ định 1 leader Le bởi hàm Hash. Baby streamlet Đề xuất khối: Ở đầu mỗi epoch, Le xác định chuỗi dài nhất nó từng thấy cho đến nay và sẽ đề xuất 1 khối liền sau chuỗi đó. Finalization : 1 replica finalizes block (và tiền tố của nó) ở đầu chuỗi. Nếu có nhiều block như thế, chọn block có epoch nhỏ nhất. Tuy nhiên, có một nhược điểm là nếu Leader là adversary và network chưa đồng bộ, thì Adversary có thể gửi thông báo các Block cho 1 user bất kì, nhưng thông báo chưa tới các user còn lại cho tới sau GST. Teen streamlet Votes: 1 vote trên block bởi replica là chữ kí của nó trên block. Notarization: 1 block được xem là Notarized dưới góc nhìn của replica nếu block đó có hơn 2n/3 chữ kí từ các replica khác. Đề xuất khối: Đầu mõi epoch e, Le xác định chuỗi Notarized dài nhất và đề xuất khối sau chuỗi Notarized này. Vote: ∆ giây ở epoch e,mỗi replica vote cho đề xuất hợp lệ đầu tiên dưới góc nhìn của Le (mở rộng chuỗi dài nhất theo góc nhìn của nó). Finalization: 1 replica finalize 1 block và tiền tố của nó sau khi thấy khối được notarized. Chứng minh: với $f < n/3$, với mỗi epoch $e$, chỉ có tối đa 1 notarized block với epoch là e trong góc nhìn của bất kì replica trung thực nào. Giả sử 2 khối cùng epoch $e$ là B và B’. Vì $f < n/3$ nên tồn tại replica vote cho cả B, B’. Mà số vote của B và B’ lớn hơn $2n/3$ \rightarrow số replica vote cho cả 2 là $> n/3$. Đây là vô lý. Vậy khi network chưa đồng bộ, giao thức này đảm bảo an toàn. Với các block có epoch khác nhau, có thể cùng ở chung 1 độ cao. Gọi 2 block đó là B1 và B2. Ban đầu, ở B, adversarial đề xuất B1 cho 66 replica trung thực, nên B1 chưa được notarized (vì có 66 vote). Tiếp theo, B2 được đề xuất bởi 1 replica trung thực, và được notarized nhưng trong đó có 1 adversarial vote cho B1, nên B1 cũng được notarized. Từ đó dẫn đến vi phạm safety. Streamlet Finalization: Khi thấy 3 khối kề nhau trong chuỗi được notarized với epoch liên tiếp, thì client sẽ finalize block thứ 2 trong 3 block trên và tẩt cả tiền tố của nó. Độ phức tạp giao tiếp là $O(N^3)$ message cho mỗi block, vì mỗn honest replica chuyển tiếp các votes nó nhận từ các replica khác cho tất cả các replica. Chứng minh tính an toàn: Safety: Giả sử có 2 block đang trong tình trạng confict ở epoch $e$ và $e’$. Nếu: $e = e$’: không thể (đã chứng minh ở Teen Streamlet). $e < e’$: suy ra $e+1 < e’$. Vì B3 được notarized nên có ít nhất $S > n/3$ replica trung thực vote cho B3 tại $e+1$. Vậy S sẽ thấy B2 được notarized ở đầu epoch $e+1$, do đó, S sẽ không vote cho B’ vì B’ không mở rộng từ chuõi dài nhất. Mà $S > n/3$ nên B’ không được notarized. $e > e’$: suy ra $e-1 > e’$. Nếu B’ được notarized, có $S > n/3$ replica trung thực vote cho nó tại epoch $e’$. Vậy S sẽ thấy B” được notarized ở đầu epoch $e”$, do đó S sẽ không vote cho B1. Tương tự, B1 không được notarized. Điều này trái với giả thiết. Hình Minh Hoạ: Vậy, Streamlet đảm bảo safety Liveness: Giả sử có 4 slot liên tiếp: $e, e + 1, e + 2, e + 3$ với leader trung thực sau GST. Ở cuối các slot này, client sẽ finalize block được đề xuất bởi các replica trung thực. Trong đó: 1 slot để undo các hành động của adversary. 3 slot để finalize block. Ngoài ra, đảm bảo không có 2 block liên tiếp nhau mà chưa được notarized. Kết Ở trên là những phần cơ bản trong giao thức blockchain, được giới thiệu trong khoá học cs251. Tiếp theo, mình sẽ trình bày về giao thức đồng thuận trên mạng.

Blockchain · 2023-07-21

Bitcoin Scripts và Ví

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Ở bài viết này, chúng ta sẽ đi sâu hơn về một số ví dụ của Bitcoin Script và các loại ví thường được sử dụng. Một số lưu ý Các Tx sau khi thêm vào khối sẽ không thể bị xoá, do đó khi Tx nhầm thì sẽ bị khoá hoặc mất tiền. Các TxID là độc nhất, vì Input của chúng là độc nhất. Có trường hợp ngoại lệ là các Coinbase vì chúng không có input. Do đó có thể có trùng TxID. Vì vậy, người ta thường thêm Block Height và mỗi ScriptPk của coinbase. Ví dụ về các loại Bitcoin Scripts Bảo vệ tài sản với co-signatory addr = 2 - of - 2 (PkA, PkS) với PkS là của Custody server. Escrow Service Giả định: A muốn mua balo từ B với giá 0.1 BTC, nhưng A chỉ có thể trả tiền khi balo đến, và không thể không trả. Do vậy, addr có dạng: 2-of-3 (PkA, PkB, PkJ). Cách vận hành: A thông báo cho B rằng muốn mua balo với giá 0.1 BTC A post 1 Tx 0.11 BTC đến addr trên (0.01BTC để đảm bảo A sẽ trả tiền cho B). B khi thấy Tx, gửi balo cho A Khi A nhận, gửi $SigA$ trong Tx trên cho B B sẽ sử dụng $SigA$ và $SigB$ để lấy số tiền mà A gửi lên Addr. Nếu vi phạm xảy ra: B không đưa balo, A sẽ lấy lại tiền với sự trợ giúp của Judge (PkJ). A không đưa $SigA$, B sẽ lấy tiền với sự giúp đỡ của Judge, A mất thêm 0.01BTC. Minh hoạ Ví Ví giúp user tạo ra các cặp $Pk- Sk$, tạo ra và xác minh các Tx, đưa ra số dư mà user có. Giúp đơn giản hoá xác minh thanh toán Để xác minh một thanh toán đã thực hiện, ví thường tải các block headers. Sau đó, ví gửi lên server danh sách các địa chỉ mà ví đang nắm giữ. Sau đó, server sẽ gửi về ví các Tx liên quan đến địa chỉ và Merkle Proof của Tx đó. Từ đó giúp ví hiển thị đúng số dư và xác minh Tx. Vấn dề Để giải quyết được yếu tố bảo mật, blockheader sẽ được tải từ 10 servers khác nhau hoặc từ 1 nodes tin cậy. Remote server có thể kiểm tra xem addr gửi lên có thuộc về ví hay không. Các loại ví Có 2 loại ví chính là Hot wallet và Cold wallet Hot wallet Dạng ví điện tử có kết nối Internet, có nhiều chức năng như lưu trữ, gửi nhận Tx, tokens,… Có thể truy cập từ các thiết bị Internet như máy tính, điện thoại,.. Có thể bị hack hoặc xâm nhập bởi các hacker. Cold wallet Không cho phép kết nối Internet. Có thiết bị riêng cho cold wallet, thiết bị này phải được khởi động bất cứ khi nào sử dụng và người dùng phải sao chép vật lý dữ liệu từ online device sang offline và ngược lại. Kết luận Có nhiều loại Bitcoin Script khác như CrossChain,… được sử dụng rất phổ biến ở hiện tại.

Blockchain · 2023-07-21

Cơ chế Bitcoin

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Cách vận hành Trong mạng lưới Bitcoin, với mỗi Miner, họ sẽ thông thường được connect với 8 người khác. Khi một Tx được gửi đến, Miners sẽ thông báo là nhận được Tx trên mạng P2P. Mọi miners sẽ xác thực rằng Tx đã nhận và lưu vào trong Mempool. Mempool là nơi chứa những Tx đang chờ được xử lý. Các nodes này chia sẻ dữ liệu mempool với nhau bằng cách chuyển tiếp các Tx đã kí với nhau cho đến khi nó được toàn bộ mạng lưới. Thời gian đóng các khối Cứ sau mỗi 10 phút, mỗi miner sẽ tạo 1 block tiềm năng từ các Tx trong mempool của nó. Các Tx được ưu tiên theo phí giao dịch. 1 miner được chọn (sau khi giải được bài toán PoW) sẽ phân tán block đó cho toàn mạng và mọi miner khác sẽ xem được block, sau đó block được đưa vào chuỗi. Phần thưởng là 6.25 BTC. Phần thưởng này được gửi cho miner thông qua coinbase Tx (là Tx đầu tiên trong block chứa địa chỉ ví của miner do ,miner thêm vào). Cấu trúc của một Transaction Transaction trong Bitcoin chia làm 2 phần chính là Input và Output. Input gồm 3 phần chính: Previous Tx ID: ID của Tx trước đó mà tạo ra Bitcoin ở Output để sử dụng trong giao dịch hiện tại. Previous Tx index: Vì một Tx có thể có nhiều Output nên index này được sử dụng để xác định output trong Tx trước đó. Danh sách các output được xem như 1 tập hợp bên trong Tx. ScriptSig: Script Signature. Nó mã hoá Public key và chữ kí của người sở hữu Bitcoin ở hiện tại. Output: là những bitcoin mới được khoá với Hash của Public Key của người nhận. Bitcoin sử dụng mô hình UTXO là Bitcoin chỉ có thể sử dụng 1 lần, sau mỗi giao dịch thì bitcoin cũ sẽ bị loại bỏ và một lượng bitcoin mới được tạo ra. Output gồm 2 phần chính: Value: Số lượng bitcoin mà được gửi cho người nhận. (Min: 1 satoshi = 10^-8 BTC) ScriptPubKey: Là một dãy các chỉ dẫn (Như 1 hàm) mà nhận ScriptSig là Input và trả về True nếu người sở hữu hợp lệ mở khoá Bitcoin này. Ngược lại, nó trả về false. Một giao dịch có thể có nhiều Input và Output. Các input có thể từ nhiều user (gọi là MultiSig Tx), các output có thể đến nhiều user. Ngoài ra, trong Tx còn có 2 phần khác là segwit và locktime. Miner xác minh một Tx như thế nào Một Tx thoả mãn khi: $ScriptSig |ScriptPK$ trả về True. Tức là với điều kiện nào thì UTXO có thể được tiêu. $TxID|index$ : hiện ở trong tập các UTXO $\sum (Input values) > \sum (Output values)$: Không thể tiêu nhiều hơn số tiền đang có. Sau khi 1 Tx được post lên, miners sẽ xoá UTXO tương ứng của nó trong tập. Các loại Tx Pay to public key hash (P2PKH) Trước tiên, mọi người cần hiểu về một số OP codes hoạt động trong Bitcoin Script ở đây. Giả sử Alice muốn gửi cho Bob 5BTC. Alice và Bob sẽ làm các bước sau: Bob tạo sig : gọi $Gen()$: (pkB, skB) Bob tính địa chỉ bitcoin của mình bằng: $addrB = H(pkB)$ Bob gửi $addrB$ cho Alice Alice tạo giao dịch Tx-fund với $Output[0]$ là: $UTXO[0] : 5, ScriptPkB$ với $ScriptPkB$ là: DUP HASH256 <<addrB>> EQVERIFY CHECKSIG còn ở Input, Alice có ScriptSig để xác thực Bitcoin của Alice có chứa chữ ký của Alice lên Tx này, khiến cho không ai có quyền thay đổi ScriptPkB. Sau đó, Bob muốn sử dụng $UTXO[0]$ thì sẽ tạo 1 Tx-spend với $ScriptSigB$ trong input, bao gồm: « sig » « pkB » với $Sig = Sig(skB, Tx)$ (Tx này là Tx-spend nhưng không chứa các ScriptSig). Miner có thể xác thực $ScriptSigB|ScriptPkB = true$ và cho phép Bob sử dụng số tiền. Một số lưu ý như: Người nhận (Bob) không thể tiết lộ $PkB$ cho đến khi UTXO được dùng (vì bảo mật). Vì tránh việc tấn công bằng cách thay đổi Sig, Sig được chuyển vào phần witness và TxID được tính bằng: $TxID = H(Tx$ không chứa witness $)$. Pay to script hash (P2SH) Người nhận (Bob) thay vì tạo address là $H(pkB)$ thì tạo 1 redeem script, sau đó gán địa chỉ để người gửi (Alice) chuyển qua thành H(redeem script). Ví dụ: ScriptPK ở UTXO: HASH160 <<H(redeem script)>> EQUAL ScriptSig để tiêu: {sig1 , sig2, …, sign, redeem script} Từ đây, người gửi (Alice) có thể thêm các điều kiện phức tạp để xác định khi nào người nhận (Bob) có thể tiêu. Reedem Script: là các điều kiện thoả mãn để có thể sử dụng UTXO như: số chữ kí tối thiểu, thời gian,… Các miner xác minh bằng cách: $ScriptSig|ScriptPk = true$: Bob gửi đúng script. $ScriptSig = true$: script là thoả mãn (tức là sẽ tồn tại điều kiện để Bob có thể dùng UTXO). Ví dụ: MultiSig Muốn dùng UTXO thì cần $t/n$ chữ kí. Ví dụ với $2 / 3$ chữ kí. Redeem Script và ScriptSig được viết như sau: Redeem Script: 2, PK1, PK2, PK3, 3, CHECKMULTISIG ScriptSig: 0, sig1, sig3, redeem script Kết luận Ở trên là 2 dạng Tx được sử dụng nhiều trong bitcoin, cũng là cơ chế bitcoin hoạt động. Ngoài những dạng Tx ở trên, sẽ có nhiều dạng Tx khác được sử dụng ở trong nhiều trường hợp cụ thể.

Blockchain · 2023-07-20

Cấu tạo block và PoW

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Trong bài viết ngày hôm nay, mình sẽ nói kĩ hơn về cấu tạo của block trong blockchain và cơ chế đồng thuận PoW (Proof of Work). Cấu tạo block trong bitcoin Các block chứa các dữ liệu về Tx được lưu vào trong sổ cái công khai. Block có các header, nơi chứa các siêu dữ liệu giúp quản lý block đó. Kích thước blockheader là 80 bytes, trong khi các giao dịch trung bình khoảng 250 bytes và mỗi khối trung bình chứa được 500 Tx. Ở trong blockheader chứa các dữ liệu liên quan đến các block đó: Đầu tiên, là giá trị hash của block liền trước nó (32 bytes), giúp đảm bảo liên kết trong chuỗi. Tiếp theo là Version (4 bytes) là phiên bản của block hiện tại. Merkle Root cũng được lưu ở đây (32 bytes), là giá trị hash của của gốc cây Merkle của các Tx. 4 bytes Timestamp là chỉ thời gian block được tạo, được tính bằng số giây từ 01/01/1970. Tiếp theo là Hash Target/ Difficult Target (4 bytes) là giá trị hash mục tiêu của PoW cho block này. Cuối cùng là số nonce (4 bytes), là giá trị mà các miner tìm để giải bài toán PoW. Minh hoạ: Proof of Work PoW là một phần dữ liệu khó tạo (là đáp án cho một bài toán) hoặc rất tốn kém, mất thời gian để tạo nhưng chỉ tốn 1 thời gian rất ngắn (complexity O(1)) để có thể kiểm tra xem đáp án đó có đúng không. Quy trình tạo dữ liệu này là ngẫu nhiên với xác suất thấp, cần thử sau rất nhiều lần trước khi tạo ra PoW hợp lệ. PoW là cách để các nodes cùng đồng thuận về tình trạng của block, tránh việc chi tiêu kép, từ đó cho phép cập nhập blockchain theo các quy tắc của hệ thống. Ví dụ với Bitcoin Trong quá trình tạo khối, các miner sẽ phải giải được bài toán tìm số nonce để đưa vào blockheader và khiến block hợp lệ. Block hợp lệ là block có hash nhỏ hơn target value hiện tại. Hash của block là lấy tổng của: Merkle Root, Version, Timestamp, Target, PreviousHash, Nonce và hash 2 lần, nếu Hash này nhỏ hơn hoặc bằng Target value, tức là block này hợp lệ. Block này sau đó sẽ được đưa vào chuỗi sau khi các nodes khác verify rằng nonce này là hợp lệ (với độ phức tạp O(1)). Ngược lại, các miner sẽ phải tìm số Nonce khác. Độ khó (Target value) sẽ được thay đổi sau 2016 block (2 tuần) được sinh ra. Nếu thời gian sinh 2016 block này nhanh hơn, Target sẽ được điều chỉnh xuống, ngược lại sẽ tăng lên. Sau khi cập nhập, các nodes cùng chia sẻ một Target. Incentive Sau khi tạo được block, miner sẽ nhận phần thưởng và Tx phí thông qua coinbase mà họ đưa vào block. Coinbase là giao dịch đầu tiên trong block, được tạo bởi miner nhằm mục đích nhận phần thưởng và Tx phí. Do đó, coinbase không có input, chỉ có output là địa chỉ ví của miner. Bitcoin nhận được từ coinbase không thể được sử dụng cho đến khi đạt 100 xác nhận trong blockchain. Kết luận Ở trên là những hiểu biết của mình về cấu tạo chung của blockchain. Tuy nhiên mỗi loại blockchain sẽ có cấu tạo khác nhau một chút. Thêm vào đó, PoW là một cơ chế đồng thuận được sử dụng ở nhiều blockchain khác nhau, tuy nhiên nó cũng mang lại nhiều bất lợi. Những cơ chế đồng thuận khác sẽ được viết ở những bài sau.

Blockchain · 2023-07-20

Kĩ thuật Blockchain

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Blockchain cung cấp sự tin cây cho nhiều bên (mà không cần đến trung gian), đây là ứng dụng có thể xem là mạnh mẽ nhất của blockchain. Dưới đây, mình sẽ viết sâu hơn về các kĩ thuật được sử dụng trong blockchain. Các tầng của Blockchain Blockchain có thể chia thành các tầng chính như sau: Application layer Bao gồm các DApps, Smartcontract, các phần mềm chạy trên đỉnh các network. Đây là tầng cho phép build các Apps và Service phục vụ người dùng. Consensus layer Là tầng mà các nodes đồng ý về tính hợp lệ của các giao dịch, dựa trên các cơ chế đồng thuận. Network layer Là tầng mà các nodes giao tiếp với nhau (P2P). Tầng này phục vụ việc kết nối, lan truyền các Tx và phân phối các dữ liệu trên mạng. Đây cũng là tầng mà các block được tạo ra và thêm vào chuỗi. Data layer Là tầng lưu trữ dữ liệu an toàn và bất biến. Các dữ liệu bao gồm sổ cái, cơ sở dữ liệu trạng thái (Hash, Merkle Tree, Tx, Chữ ký,..). Hardware layer Là tầng vật lý, các thiết bị như máy tính, servers, routers,… Ở tầng Consensus, các nodes phải đảm bảo các tính chất sau: Persistence: Khi các Tx và block được thêm vào chuỗi, không thể xoá bỏ Safety: Các thành viên tham gia (các nodes, người dùng) đều có chung 1 dữ liệu về sổ cái Liveness: các thành viên Honest (không phá hoại mạng blockchain) thêm được các giao dịch Open: Ai cũng có thể thêm các giao dịch. Cùng với đó, có những vấn đề xảy ra ở tầng Consensus này cần giải quyết đó chính là việc Network delays, Network Partition, Crash, Malice,.. dẫn đến danh sách các Tx có thể bị sai thứ tự, không đầy đủ,… Mã hoá Hàm Hash H là một hàm mã hoá được sử dụng với ý nghĩa sau: Với 2 tập hợp M và T có: $|M| \gg |T|$ thì hàm hash H: $|M| \rightarrow |T|$ có ý nghĩa là nhận input thuộc tập $M$ và đưa ra output thuộc tập $T$. Ví dụ khi input có giá trị lên đến cả megabyte, $T=\lbrace0, 1\rbrace^{256}$ khi chuyển qua hàm hash H sẽ có dạng 32 bytes. Một hàm hash như trên gọi là chống trùng lặp nếu như rất khó để tìm ra 1 cặp $(x, y) \in M$ sao cho $x \ne y$ mà $H(x) = H(y)$. Hàm này còn được gọi là CRF (Collision Resistant Function). Commit dữ liệu lên blockchain Nếu user $A$ có file $m: h = H(m)$ là cam kết ràng buộc cho $m$. Với một danh sách $S = (m_1,…m_n)$, $h = H(S)$. Khi user $B$ đọc $h$, cho $(m_i, proof \pi_i)$ có thể kiểm tra xem $S[i]$ có bằng $m_i$ hay không. Điều này tương đương với khi chạy hàm $verify(h, i, m, \pi_i)$ sẽ ra 1 trong 2 kết quả: accept/reject. Ngoài ra, để đảm bảm security, không thể tìm được bộ $(S, i, m, \pi)$ mà $m \ne S[i]$ và $verify(h, i, m_i, \pi_i)$= accept. Merkle Tree Mục tiêu của Merkle tree là khi commit danh sách $S$ ở trên, có thể chứng minh được $mi = S[i]$. Cây merkle được xây dựng như sau: Các phần tử $i$, cha của chúng là $H(i, sib(i))$ với $sib(i)$ là con kề với $i$. Ví dụ $y1$ là $H(m_1, m_2)$. Bây giờ, với bài toán chứng minh ở trên, ví dụ cần chứng minh $S[4] = m_4$, ta chỉ cần set $Proof = (m_3, y_1, y_6)$. Lý do: $y_2 \leftarrow H(m_3, m_4)$ $y_5 \leftarrow H(y_2, y_1)$ $h’ \leftarrow H(y_5, y_6)$ Nếu $h = h’$ thì accept. Khi muốn post 1 block vào trong chain, cần viết commit(S) vào. Merkle tree được sử dụng để chứng minh một Tx có ở trong block hay không, hiển thị số dư,… Chữ kí số Làm cách nào mà các nodes có thể xác thực được các Tx? Thực tế, để xác định cần 3 thuật toán: $Gen()$: tạo ra cặp key $(pK, sK)$ cho user. $Sign(sK, msg)$: người gửi kí secretKey với $msg$ họ muốn gửi. Output: là 1 sig: $σ$ $Verify(pK, msg, σ)$. Output: accept / reject Khi tạo ra các Tx, user đưa $Sk$ + $msg$ để tạo ra chữ kí $σ$. Các verifier sẽ sử dụng $pK$, $msg$ và $σ$ để verify các Tx. Việc sử dụng chữ kí số này giúp đảm bảo uỷ quyền Tx, khả năng bầu cử và sự đồng thuận bỏ phiếu của user. Tạm kết Ở phần này là những kĩ thuật phổ biến được sử dụng trong blockchain. Trong bài tiếp theo, mình sẽ đi sâu về cấu tạo của từng khối và cách hoạt động của PoW.

Blockchain · 2023-07-15

Tổng quan về Blockchain

Đây là kiến thức mình tìm hiểu được từ khóa học CS251 của đại học Stanford. Mọi người có thể truy cập vào khóa học này để đọc thêm các tài liệu và bài giảng bằng tiếng Anh. Blockchain là một xu thế đang khá nổi ở thời điểm hiện tại. Theo những gì mình tìm hiểu và học hỏi được (cụ thể là từ khoá học CS251), đây là những chia sẻ tổng quan của mình về blockchain Blockchain là gì Blockchain là một sổ cái số phi tập chung ghi lại các dữ liệu giao dịch một cách an toàn, được duy trì bởi các máy tính chuyên dụng trên mạng (hay gọi là các nodes). Nó đảm bảo tính toàn vẹn bất biến thông qua cơ chế mã hoá và đồng thuận. Khi một giao dịch đã được record, nó sẽ không thể bị thay đổi. Nói một cách đơn giản, blockchain như một loại cơ sở dữ liệu đặc biệt, được duy trì phi tập trung bởi nhiều máy tính phân bổ khắp thế giới. Ngoài ra, dữ liệu trên từng block sắp xếp theo trình tự thời gian, và bảo mật bằng mật mã để tránh bị làm giả dữ liệu Sự phi tập trung trong blockchain Trong Blockchain, quyền quyết định và điều khiển của mạng lưới thì phân bổ cho các user thay vì tập trung tại 1 user hoặc 1 tổ chức. Các giao dịch (Tx) được verified và ghi vào mạng máy tính phân tán hoạt động cùng nhau để duy trì tính toàn vẹn. Ở trong core, blockchain lưu giao dịch giữa 2 bên. Khi 1 user gửi 1 Tx, nó được truyền đi khắp mạng lưới. Các nodes xác minh giao dịch bằng xác minh chữ kí số (Digital Signature) và các thông tin khác. Khi giao dịch được xác minh, nó sẽ cùng với các Tx khác được thêm vào block. Các block sẽ liên kết với nhau bằng phương pháp mã hoá, tạo thành chuỗi. Quá trình xác minh và thêm vào chuỗi sẽ được thông qua cơ chế đồng thuận. Cơ chế đồng thuận và mã hoá Cơ chế đồng thuận là tập hợp các quy tắc chi phối các node có đồng thuận về trạng thái của chuỗi hiện tại và tính hợp lệ của giao dịch hay không. Điều này đảm bảo các nodes trong mạng sẽ đều có bản copy đầu đủ của sổ cái. Mã hoá là chìa khoá duy trì bảo mật, minh bạch và chống giả mạo của blockchain. Có 2 cách mã hoá chính được sử dụng là Hash và cặp khoá: Với Hash, là hàm không thể đảo ngược, giúp chuyển 1 input ở 1 size bất kì sang 1 size cố định. Mỗi khối trong chuỗi chứa hash của khối liền trước nó, nên khi muốn thay đổi 1 khối thì cần phải thay đổi các khối tiếp theo. Điều này giúp giảm khả năng bị thay đổi của khối xuống còn rất nhỏ. Người dùng có 1 cặp khoá Secret - Public của mình. Khi tạo 1 Tx, người đó sử dụng Secret key để kí và tạo chữ kí số. Những người khác xác nhận tính xác thực của Tx này bằng cách áp dụng Public key của người gửi. Crypto Currency Tiền điện tử (Tiền mã hoá) là 1 loại tiền kĩ thuật số phi tập trung, sử dụng mật mã để bảo mật. Nó có thể hoạt động độc lập với các trung gian như ngân hàng, cổng thanh toán,.. Việc phi tập trung tạo điều kiện thuận lợi cho các giao dịch ngang hàng (P2P) giữa các cá nhân thông qua các ví điện tử hoặc sàn giao dịch. Các tiền điện tử luôn nằm trong blockchain. Trong trường hợp các sàn giao dịch, nó chứa Secret key cho phép người dùng truy cập vào các tiền đó. Crypto Currency hoạt động như thế nào ? Crypto Currency sử dụng thuật toán toán học tiên tiến để bảo mật các giao dịch và bảo vệ dữ liệu khỏi bị truy cập hoặc thao tác trái phép. Các thuật toán phục vụ 2 chức năng chính là: Duy trì quyền riêng tư của người dùng và xác minh tính xác thực của Tx. Crypto whitepaper là một document mô tả chi tiết kèm các thông số kĩ thuật về 1 dự án blockchain. Các thông tin nó bao gồm rất đa dạng, có thể kể đến như: project goals, works, tech, roadmap,… Stable coin Một loại tiền điện tử được thiết kế để duy trì một giá trị cố định. Nó có thể trace giá trị tiền tệ fiat (tiền tệ được các nước sử dụng chính thức) hoặc các loại tài sản khác. SmartContract Hợp đồng thông minh là một thoả thuận kĩ thuật số được lập trình và lưu trữ trong blockchain, tự vận hành không cần trung gian. Nó có tính bảo mật, minh bạch, cung cấp cho người dùng sự tự do trao đổi, an toàn, khi triển khai các giao dịch. Hợp đồng thông minh được xem là xương sống của các DApps. Bất cứ ai truy cập vào blockchain có thể gọi SmartContract và tương tác với nó. DApp Decentralized Application (DApp) là ứng dụng phi tập trung được xây dựng trên các nền tảng blockchain. Các ứng dụng này sử dụng SmartContract, và hoạt động không cần sự can thiệp của bất kì bên trung gian nào. Với DApp, mọi thứ đều được mã hoá, bất biến, an toàn, bảo mật và không ai có quyền thay đổi, lừa đảo, gian lận. Nodes Là các moderators xây dựng cơ sở cho mạng phi tập trung. Nó lưu trữ bản copy của sổ cái, được đồng bộ hoá và lập trình để thực hiện các giao dịch theo sự đồng thuận của đa số. Các nodes có thể là các máy tính, router,… Tạm Kết Đây chỉ là những khái niệm cơ bản về blockchain. Những khái niệm này sẽ được phân tích chi tiết hơn ở những bài viết sau. Ở bài tiếp theo, mình sẽ đi sâu vào cách hoạt động cụ thể của Blockchain.

Blockchain · 2023-07-14

VanhGer

Contact

Cs251