Người dùng Bitcoin chỉ cần BTC trên Bitcoin để ép rút BTC của họ từ BOB trở lại Bitcoin. Chúng tôi đang làm việc trên một giải pháp kết hợp: mặc định đến Ethereum như DA trong khi cho phép người dùng ép rút giao dịch trên BOB thông qua một giao dịch đặc biệt trên Bitcoin. Chúng tôi rất vui mừng chia sẻ công việc đang tiến hành trong bài đăng trên blog này.

tl;dr

• L2s nên có sự chống kiểm duyệt tương tự như L1 mà chúng dựa vào
• Trên BOB, người dùng đã có thể rút bắt buộc tài sản của họ từ BOB sang Ethereum qua giao dịch Ethereum
• Đối với cầu nối BitVM của nó, BOB đang làm việc để tích hợp Bitcoin như một cách cho người dùng thực hiện giao dịch trên BOB.
• Người dùng Bitcoin sẽ có thể rút BTC của mình từ BOB mà không cần gửi giao dịch đến BOB

Một trong những đặc tính cốt lõi của L2s là trạng thái của họ cần phải tiến triển ngay cả khi sequencer đang offline. L2s đạt được điều này bằng cách đọc và ghi trạng thái của chúng từ một lớp cung cấp dữ liệu (DA) có thể được cập nhật độc lập với L2 đang hoạt động trực tuyến. Như vậy, người dùng có thể buộc việc bao gồm giao dịch của họ ngay cả khi bộ xếp hàng ngoại tuyến hoặc bộ xếp hàng không chấp nhận giao dịch của họ trực tiếp.

Đối với cầu BitVM của BOB, điều này đặt ra một vấn đề thú vị. Hiện tại, BOB đang sử dụng các khối Ethereum EIP-4844 làm lớp DA của mình. Người dùng trên Ethereum có thể dễ dàng kích hoạt rút tiền về Bitcoin thông qua cầu BitVM. Tuy nhiên, điều này yêu cầu người dùng phải có ETH trên Ethereum.

Điều này không đủ tốt đối với chúng tôi: Người dùng Bitcoin chỉ cần BTC trên Bitcoin để buộc rút BTC của họ từ BOB trở lại Bitcoin. Chúng tôi đang làm việc trên một giải pháp lai: mặc định là Ethereum như DA trong khi cho phép người dùng buộc bao gồm các giao dịch trên BOB thông qua một giao dịch đặc biệt trên Bitcoin. Chúng tôi hào hứng chia sẻ công việc đang tiến hành của chúng tôi trong bài đăng blog này.

Một khái niệm cơ bản về DA và phái sinh

Quá trình phái sinhđối với L2s rất quan trọng: toàn bộ trạng thái L2 của BOB cần được xây dựng từ L1 và lớp DA. Điều này cho phép L2s tận hưởng sự chống kiểm duyệt tương tự như lớp DA, trong trường hợp của chúng tôi là Ethereum.

Đơn giản hóa, trong rollups (cụ thể là OP Stack chains), chúng ta có hai loại dữ liệu trên L1:

• Giao dịch nạp tiềnđã thực hiện vào hợp đồng “OptimismPortal”. Đây là những giao dịch được người dùng thực hiện trên Ethereum thông thường để gửi tài sản của họ vào BOB. Những giao dịch gửi tiền này cũng có thể được sử dụng để thực hiện các giao dịch khác trên BOB.
• Các lô được gửi bởi bộ xử lý tuần tự (hoặc op-batcher để chính xác hơn) từ giao dịch L2. Đây bao gồm tất cả các giao dịch được thực hiện trực tiếp bởi người dùng trên BOB và cuối cùng sẽ được bao gồm trở lại Ethereum blobs.

Bitcoin như một lớp DA

Nếu chúng ta muốn Bitcoin trở thành một lớp DA, tại sao không hoàn toàn chuyển sang sử dụng Bitcoin hoàn toàn như một lớp DA? Câu trả lời chủ yếu là chi phí. Bitcoin có ít không gian lưu trữ (khoảng 4MB khoảng mỗi 10 phút), do đó, chi phí lưu trữ cao.

Tuy nhiên, trong trường hợp của chúng tôi, BOB vẫn có thể sử dụng Ethereum làm lớp DA “chính” của nó, nơi nó đăng toàn bộ dữ liệu giao dịch của mình, nhưng thêm Bitcoin làm lớp dự phòng chống kiểm duyệt cao nếu Ethereum DA không khả dụng. Về cơ bản, Ethereum trở thành lớp DA lạc quan trong khi Bitcoin trở thành phương sách cuối cùng đắt tiền nhưng có khả năng chịu lỗi.

Ống dẫn pha trộn

Giải pháp cơ bản là thêm Bitcoin vào BOB như là một phần của đường ống suy luận, sao cho BOB (và cụ thể là “nút-op”) xử lý đầu vào theo thứ tự này:

1. Giao dịch rút tiền bắt buộc Bitcoin (mới thêm vào đặc biệt cho BOB)
2. Khoản tiền gửi Ethereum đến hợp đồng OptimismPortal của BOB (tiêu chuẩn OP Stack)
3. Nhóm Ethereum từ op-batcher (tiêu chuẩn ngăn xếp OP)

Hãy bắt đầu vào một giải pháp có thể mã hóa các giao dịch rút Bitcoin bắt buộc vào đường ống phát sinh BOB. Lưu ý rằng điều này vẫn đang được nghiên cứu, vì vậy có thể có sự thay đổi.

Giao dịch Rút Bitcoin Bắt Buộc

Chúng ta sẽ cần ba phần để tạo giao dịch rút bắt buộc:

1. Xây dựng giao dịch rút buộc trên Bitcoin.
2. Lưu giao dịch rút buộc trên Bitcoin trong giới hạn kích thước của Bitcoin.
3. Xử lý chi phí gas cho giao dịch rút bắt buộc trên Bitcoin.

1. Xây dựng giao dịch rút bắt buộc

Một ngăn xếp OPgiao dịch nạp tiềncó cấu trúc sau:

• bytes32 sourceHash: source-hash, định danh độc nhất nguồn gốc của khoản tiền gửi.
• địa chỉ từ: Địa chỉ của tài khoản người gửi.
• địa chỉ đến: Địa chỉ của tài khoản người nhận, hoặc địa chỉ null (độ dài bằng không) nếu giao dịch gửi tiền là việc tạo hợp đồng.
• uint256 mint: Giá trị ETH để tạo mới trên L2.
• giá trị uint256: Giá trị ETH để gửi cho tài khoản người nhận.
• uint64 gas: Giới hạn gas cho giao dịch L2.
• bool isSystemTx: Nếu đúng, giao dịch sẽ không tương tác với hồ bơi gas khối L2.
• dữ liệu bytes: calldata.

Giao dịch rút buộc yêu cầu bao gồm giao dịch rút đã được mã hóa trong trường dữ liệu của giao dịch nạp tiền. Điều này được thực hiện bằng cách tạo giao dịch trên BOB, kích hoạt việc rút tiền từ BOB sang Bitcoin và hoạt động hoàn toàn giống như khi giao dịch được gửi từ Ethereum.

Chúng ta có thể lưu trữ một phiên bản (nén) của giao dịch rút buộc phải trên Bitcoin bao gồm tất cả dữ liệu trên.

2. Lưu giao dịch Rút Bắt Buộc trên Bitcoin

Vì dữ liệu cho giao dịch rút tiền bắt buộc lớn hơn dữ liệu thường được lưu trữ trong đầu ra OP_RETURN, chúng tôi có thể sẽ sử dụng Taprootđầu ra để lưu trữ dữ liệu.

Trong khi dễ dàng nhận ra giao dịch nạp tiền (có thể bao gồm rút tiền) trên Ethereum do nó được gửi đến hợp đồng OptimismPortal của BOB, thì không dễ dàng nhận ra giao dịch rút tiền bắt buộc trên Bitcoin.

Serialization dữ liệu: Giao dịch rút tiền bị buộc phải được tuần tự hóa bằng cách sử dụng kịch bản Taproot trong một cấu trúc “phong bì”. Chúng là các noops trên mạng Bitcoin và được sử dụng, ví dụ, cho Ordinals cũng như. Chúng tôi điều chỉnh cấu trúc để phù hợp với nhu cầu của chúng tôi.

Unset
OP_FALSE OP_IF
OP_PUSH “bob”
OP_1
OP_PUSH “transaction”
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Two-Phase Commit/Reveal Scheme:
Tương tự như với các số thứ tự, người dùng sẽ phải gửi hai giao dịch đến Bitcoin:

• Commit Transaction: Tạo một đầu ra Taproot cam kết với script chứa nội dung chữa. Giao dịch này vẫn chưa tiết lộ dữ liệu và chúng ta sẽ cần giao dịch thứ hai cho các nút đầy đủ của BOB và các bộ xếp hàng để bao gồm giao dịch rút tiền.
• Reveal Transaction: Sử dụng đầu ra từ giao dịch cam kết, tiết lộ thông tin trên chuỗi, tức là tiết lộ giao dịch rút tiền của người dùng để được bao gồm trong BOB.

3. Xử lý Chi phí Gas cho Giao dịch Rút bắt buộc

Đây là vấn đề mở nhất cho đến nay, với hai lựa chọn hiện đang được xem xét:

• Đặt gas thành 0 cho giao dịch rút buộc phải trên Bitcoin và khấu trừ chi phí gas từ số dư ETH của người dùng trên BOB. Như vậy, chỉ những người dùng có ETH trên BOB mới có thể buộc rút. Tuy nhiên, đây không phải là một lựa chọn tốt vì điều này đòi hỏi người dùng phải có ETH trên BOB để buộc rút, tức là người dùng có BTC trên Bitcoin không thể buộc rút.
• Gas được người dùng thanh toán bằng BTC trên Bitcoin. Mạng BOB sẽ cần có một địa chỉ trên Bitcoin có thể nhận BTC và sẽ hiệu quả chuyển đổi BTC nhận được từ người dùng thành ETH trên BOB để thanh toán phần chi phí gas L1 cùng chi phí thực thi. Tùy chọn này có thể được sử dụng bởi BOB gatewayvà cài đặt địa chỉ EVM của BOB DAO là người nhận BTC.

Chúng tôi cũng đang thử nghiệm với nhiều ý tưởng khác, vì vậy hãy tiếp tục theo dõi để cập nhật thêm!

Đặt tất cả lại với nhau

Bất kỳ ai cũng có thể xác định trạng thái của BOB chỉ bằng cách kiểm tra dữ liệu trên Bitcoin và Ethereum:

1. Đọc tất cả các giao dịch rút tiền từ Bitcoin. Chúng được mã hóa dưới dạng hai giao dịch cho mỗi lần rút tiền, tức là một giao dịch commit và một giao dịch reveal. Đây là sự bổ sung mà chúng tôi đang thực hiện cho OP Stack và nơi chúng tôi cải tiến quy trình thu được.
2. Đọc tất cả các giao dịch được thực hiện đến hợp đồng OptimismPortal của BOB trên Ethereum. Điều này đã là một phần của quy trình phân tích ngăn xếp OP tiêu chuẩn.
3. Đọc tất cả các giao dịch được thực hiện trực tiếp trên BOB và được tích hợp như một phần của các lô trên Ethereum. Quan trọng nhất, các nút đầy đủ không đọc trực tiếp từ bộ xử lý chuỗi để nhận các giao dịch đã xác nhận mà họ đọc từ các đám mây Ethereum. Điều này đã là một phần của đường ống suy ra chuỗi OP tiêu chuẩn.

Thách thức kỹ thuật

Sự nhất quán dữ liệu: Trong khi đảm bảo sự nhất quán dữ liệu giữa các chuỗi Ethereum và Bitcoin là quan trọng, việc có dữ liệu giao dịch trên cả hai chuỗi không đảm bảo tính hợp lệ. Giao dịch phải biểu thị các chuyển đổi trạng thái hợp lệ theo hàm chuyển đổi trạng thái của rollup để được coi là hợp lệ. Giải pháp yêu cầu thực hiện logic xác thực trong op-node (hoặc các cài đặt lớp nhất trí khác) kiểm tra xem một giao dịch có dẫn đến một thay đổi trạng thái hợp lệ trước khi chấp nhận nó hay không.

Bằng chứng gian lận và tính hợp lệ: Hệ thống chống gian lận cho cả BitVM và Ethereum cần được tăng cường để xử lý dữ liệu từ cả hai chuỗi, điều này có thể làm cho việc giải quyết tranh chấp phức tạp hơn. Để giải quyết vấn đề này, chúng ta cần tính toán chính xác các giao dịch có thể có từ Bitcoin và Ethereum như một phần của cầu nối BitVM và thanh toán của BOB trên Ethereum.

Tăng Lưu Trữ: Ngoài ra, các nút BOB trong mạng đối mặt với yêu cầu lưu trữ và băng thông tăng lên do họ cần xử lý và lưu trữ dữ liệu từ Bitcoin và Ethereum. Tuy nhiên, chúng ta có thể giảm thiểu điều này bằng cách yêu cầu rằng các giao dịch BOB được thực hiện trên Bitcoin cần phải được bao gồm trong các đoạn văn Ethereum với tham chiếu đến các khối Bitcoin mới nhất. Như vậy, các nút chỉ cần đồng bộ hóa các khối Bitcoin gần đây.

Bước tiếp theo

Chúng tôi rất phấn khích khi đẩy mạnh sự kết hợp giữa lớp cuốn hybrid kết hợp bảo mật của Bitcoin với sự đổi mới của Ethereum. Trong vấn đề cụ thể này, chúng tôi quan tâm đến việc kết hợp khả năng chống kiểm duyệt giao dịch của Bitcoin với ngăn xếp cuốn BOB. Chúng tôi sẽ cập nhật bài viết blog này với thêm thông tin khi chúng tôi tiến bộ.

Miễn trừ trách nhiệm:

1. Bài viết này được sao chép từ [gate]BOB]. Tất cả bản quyền thuộc về tác giả gốc [Dominik Harz]. Nếu có ý kiến ​​phản đối việc tái bản này, vui lòng liên hệ với Gate Learnđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Miễn trách nhiệm về trách nhiệm: Quan điểm và ý kiến được biểu đạt trong bài viết này chỉ thuộc về tác giả và không thành lập lời khuyên đầu tư.
3. Nhóm gate Learn đã dịch bài viết sang các ngôn ngữ khác. Việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch là không được phép trừ khi có ghi chú.