Cảnh báo rủi ro: Đề phòng huy động vốn bất hợp pháp dưới danh nghĩa 'tiền điện tử' và 'blockchain'. — Năm cơ quan bao gồm Ủy ban Giám sát Ngân hàng và Bảo hiểm
Tìm kiếm
Đăng nhập
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
Xem thị trường
Sự khác biệt đáng chú ý nhất giữa Arbitrum và Lạc quan là gì?
巴比特
特邀专栏作者
2021-07-09 13:00
Bài viết này có khoảng 4095 từ, đọc toàn bộ bài viết mất khoảng 6 phút
Những sự đánh đổi này đáng để thảo luận vì cả hai nền tảng đều nhằm mục đích cung cấp khả năng mở rộng đầy đủ cho Ethereum trong những tháng tới.

Bởi Benjamin Simon

Hãy để tôi làm cho một điểm đầu tiên. Gần đây tôi đã tham gia vào vòng gọi vốn mới nhất của Offchain Labs (công ty phát triển Arbitrum), Mechanism Capital cũng tham gia. Mặc dù sẽ vô ích nếu giả vờ rằng quan điểm của chúng tôi trong bài viết này là khách quan, nhưng tôi hy vọng bài viết này sẽ giúp người đọc hiểu được một số điểm khác biệt chính giữa hai dự án, dù tôi có thể bị thiên vị.

Tất cả các giải pháp Tổng số đều tuân theo kiến ​​trúc cơ bản và logic bên trong tương tự nhau. Tuy nhiên, như chúng ta đã thấy trong phần đầu tiên của loạt bài này, một sự khác biệt duy nhất giữa Bản tổng hợp lạc quan và Bản tổng hợp ZK — cách hoạt động của “quy trình đánh giá” tương ứng — có ý nghĩa đối với tính bảo mật, khả năng sử dụng và khả năng tương thích với EVM.

tiêu đề cấp đầu tiên

nguồn gốc sớm

Đầu tiên, một số nền tảng lịch sử ngắn gọn về mỗi dự án là theo thứ tự. Khi nó xảy ra, cả Arbitrum và Lạc quan đều có một số câu chuyện gốc độc đáo.

Sáu năm rưỡi trước, vào một buổi sáng se lạnh ở Princeton, một nhóm sinh viên chưa tốt nghiệp làm việc với Giáo sư Ed Felten đã nói chuyện về dự án mà họ đã ký hợp đồng để tạo ra: một hệ thống trọng tài dựa trên chuỗi khối. Với mục tiêu vượt qua một số thách thức mở rộng quy mô dự kiến ​​của các nền tảng hợp đồng thông minh, kế hoạch là thiết kế một chuỗi khối dựa trên hệ thống giải quyết tranh chấp và thách thức để giảm bớt khối lượng công việc tính toán của các công cụ khai thác truyền thống. Được mệnh danh là "Arbitrum", hệ thống này sẽ chịu chung số phận như hầu hết các dự án khoa học máy tính hàn lâm đầy triển vọng khác nếu không có hai nghiên cứu sinh tiến sĩ đầy tham vọng, Steven Goldfeder và Harry Kalodner, tiếp cận Felten vài năm sau đó. Xây dựng giải pháp Lớp 2 mạnh mẽ từ khái niệm ban đầu. Ngay sau đó, Felten, Goldfeder và Kalodner đồng sáng lập Offchain Labs và biến Arbitrum từ một ý tưởng trừu tượng thành hiện thực cụ thể.

tiêu đề cấp đầu tiên

Giải quyết tranh chấp: Giới thiệu (tái) rất ngắn gọn

tiêu đề cấp đầu tiên

So sánh sơ bộ về Arbittrum và lạc quan trong giải quyết tranh chấp

Cách dễ nhất để mô tả sự khác biệt là việc giải quyết tranh chấp của Optimism phụ thuộc nhiều vào Máy ảo Ethereum (EVM) hơn là Arbitrum. Khi ai đó gửi thử thách trên Lạc quan, toàn bộ giao dịch được đề cập sẽ chạy qua EVM. Ngược lại, Arbitrum sử dụng quy trình giải quyết tranh chấp ngoài chuỗi để giảm tranh chấp xuống một bước duy nhất trong giao dịch. Sau đó, giao thức sẽ gửi xác nhận một bước này (chứ không phải toàn bộ giao dịch) tới EVM để xác minh lần cuối. Do đó, về mặt khái niệm, quy trình giải quyết tranh chấp của Optimism đơn giản hơn nhiều so với của Arbitrum.

Mô tả hình ảnh

Nguồn: Trung tâm phát triển phòng thí nghiệm OffChain

Phương pháp giải quyết tranh chấp của Optimism—nghĩa là chạy toàn bộ giao dịch thông qua EVM—không chỉ đơn giản hơn về mặt khái niệm: mà còn nhanh hơn. Không có "nhiều vòng" qua lại như trong quy trình của Arbitrum. Trên thực tế, Tổng số lạc quan thường được gọi là "các vòng đơn" vì lý do này, trong khi Tổng số Arbitrum là "nhiều vòng". Trên thực tế, điều này có nghĩa là trong trường hợp giao dịch bị tranh chấp, xác nhận cuối cùng trên Ethereum bị trì hoãn lâu hơn trong trường hợp của Arbitrum so với trường hợp của Optimism. Như chúng ta đã khám phá trong phần đầu tiên của loạt bài này, tốc độ giải quyết tranh chấp quan trọng vì nó xác định thời gian người dùng cần để hoán đổi mã thông báo trở lại Ethereum từ Rollup.

tiêu đề cấp đầu tiên

xây dựng lại so sánh

Sự đánh đổi cơ bản giữa hai thiết kế giải quyết tranh chấp dường như chỉ đơn giản là giữa tốc độ và chi phí trên chuỗi. Nhưng trên thực tế, điều này hơi quá đơn giản, bởi ít ai ngờ rằng tranh cãi lại nảy sinh vì 2 lý do sau:

  • Bộ xử lý giao dịch trên cả Arbitrum và Optimism không có động cơ tài chính nào để xử lý các giao dịch gian lận. Họ buộc phải đặt trước tài sản thế chấp/trái phiếu, số tiền này sẽ bị cắt giảm trong trường hợp giao dịch gian lận.

  • Các bên giám sát trạng thái của Rollup miễn cưỡng gửi bằng chứng gian lận sai — trong Lạc quan vì bên thách thức phải trả phí gas trên chuỗi cho bằng chứng gian lận và trong Arbitrum vì bên thách thức phải cung cấp gas bị tịch thu nếu tranh chấp thất bại Tiền gửi ký quỹ.

Vì vậy, nếu các tranh chấp được cho là ít và cách xa nhau, thì tại sao cấu trúc của quy trình giải quyết tranh chấp lại quan trọng?

Mặc dù tranh chấp hiếm khi xảy ra nhưng Rollup phải được thiết kế để xử lý tranh chấp khi có thể. Do đó, thiết kế trường hợp "gây tranh cãi" ảnh hưởng đến cấu trúc của trường hợp "không gây tranh cãi".

Vì Optimism phải có khả năng chạy mọi giao dịch thông qua EVM trong trường hợp có tranh chấp nên nó không thể xử lý các giao dịch vượt quá giới hạn gas của Ethereum vì các giao dịch này không thể được xác minh chính xác trên chuỗi. Ngược lại, Arbitrum có thể thực hiện các giao dịch lớn tùy ý ngay cả khi chúng vượt quá giới hạn gas của Ethereum, bởi vì các giao dịch không bao giờ được xử lý theo đợt thông qua EVM mà trước tiên được chia thành các "xác nhận bước" nhỏ.

Không rõ giới hạn gas của Optimism sẽ áp dụng cho các ứng dụng như thế nào trong giới hạn thực tế. Tuy nhiên, một ý nghĩa khác, có lẽ quan trọng hơn của sự khác biệt trong thiết kế giải quyết tranh chấp là Arbitrum có thể tiết kiệm xăng bằng cách giảm tần suất của các điểm kiểm tra trên chuỗi (cập nhật "gốc trạng thái"). Cụ thể hơn, Arbitrum có thể phân bổ một lượng đáng kể tính toán ngoài chuỗi cho một bản cập nhật, vì bản cập nhật gốc trạng thái đó về mặt lý thuyết có thể bao gồm các bằng chứng gian lận một bước (nhỏ) cho tất cả các giao dịch có trong nó. Mặt khác, sự lạc quan phải kiểm tra điểm trên chuỗi sau mỗi giao dịch, làm tăng đáng kể dấu ấn trên chuỗi của nó.

tiêu đề cấp đầu tiên

Giải quyết tranh chấp và các vectơ tấn công tiềm ẩn

Điểm cuối cùng về các quy trình giải quyết tranh chấp khác nhau này đáng được thảo luận: mỗi thiết kế có khả năng chống lại các cuộc tấn công tiềm ẩn như thế nào. Ở trên, chúng tôi đã nói về các biện pháp khuyến khích kinh tế để ngăn chặn các cuộc tấn công thư rác. Cụ thể hơn, cả những người xác nhận Lạc quan và Arbitrum đều không sẵn sàng gửi những thách thức không cần thiết.

Nhưng còn trường hợp kẻ tấn công ác ý không ngại gánh chịu chi phí kinh tế cho việc tổng hợp thư rác thì sao? Nói cách khác, điều gì sẽ xảy ra nếu một người hoặc tổ chức cam kết làm chậm quá trình Tổng hợp lạc quan đến mức họ sẵn sàng làm như vậy, ngay cả khi điều đó có nghĩa là liên tục trả tiền cho các thử thách giả?

Như đã đề cập ở trên, quy trình giải quyết tranh chấp của Optimism đơn giản và nhanh hơn Arbitrum vì nó chỉ cung cấp các giao dịch tranh chấp thông qua EVM. Tốc độ này là lợi thế của Optimism ở đây, vì các tranh chấp có thể được giải quyết nhanh chóng và không cản trở tiến độ của chuỗi tổng số trong tương lai.

Mối quan tâm là "nhiều vòng" của thủ tục giải quyết tranh chấp, chẳng hạn như thủ tục được sử dụng bởi Arbitrum. Ít nhất về mặt lý thuyết, những kẻ gửi thư rác có thể cản trở tiến trình của Rollup bằng cách tung ra một loạt thử thách liên tiếp, mỗi thử thách mất một khoảng thời gian đáng kể để giải quyết. Trên thực tế, đây là một vấn đề đã cản trở các lần lặp lại trước đây của Arbitrum.

Tuy nhiên, giao thức mới hơn của Arbitrum hoạt động cho vấn đề này, một giải pháp tao nhã được gọi là "pipelining". Đường ống cho phép người xác nhận mạng tiếp tục xử lý các giao dịch để phê duyệt lần cuối, ngay cả khi các giao dịch được xử lý trước đó đang bị tranh chấp. Điều này tạo ra một "đường ống" gồm các giao dịch được xử lý gần đây nhưng chưa hoàn thành, thay vì nút cổ chai ngăn cản người đặt hàng xử lý giao dịch và các bên trong mạng lưới gửi yêu cầu thách thức.

Mô tả hình ảnh

Tóm lại là

Tóm lại là

Bên cạnh thiết kế của quy trình giải quyết tranh chấp, còn có những điểm khác biệt đáng chú ý khác giữa Trọng tài và Chủ nghĩa lạc quan, đáng chú ý là

  • kiến trúc cơ sở mã của họ, và

  • Cách tiếp cận của họ đối với giá trị có thể trích xuất của người khai thác (MEV)

Để tóm tắt những điểm khác biệt một cách ngắn gọn: Lạc quan có một cơ sở mã tương đối tối giản, trong khi của Arbitrum phức tạp và tham vọng hơn; Lạc quan trước đây đã chỉ ra rằng nó ủng hộ phương pháp đấu giá MEV, trong khi Arbitrum có kế hoạch triển khai Dịch vụ phân loại công bằng (FSS). Đương nhiên, cả hai điểm so sánh này đều đáng được trình bày chi tiết trong các bài báo riêng biệt. MEV, đặc biệt, là một vấn đề tranh luận triết học giữa hai dự án - mặc dù cả hai dự kiến ​​sẽ sử dụng mô hình trình tự đáng tin cậy để đơn giản, ít nhất là trong những ngày đầu sau khi ra mắt.

Cuối cùng, lùi lại một bước so với các sắc thái ở cấp độ giao thức (cũng quan trọng như vậy), cũng có những thứ "mềm" giúp phân biệt hai đối thủ nặng ký này: chiến lược bootstrap, thiết kế khuyến khích và tinh thần cộng đồng, v.v. Trên thực tế, các bản tổng hợp lạc quan sẽ phải trở thành thế giới của riêng chúng chứ không chỉ là một phần phụ của Ethereum nếu chúng muốn thành công về lâu dài. Do đó, mở rộng quy mô không phải là một cuộc chạy đua vũ trang mà là một cuộc chiến trên nhiều mặt trận. Nó có thể có một người chiến thắng; nó có thể có nhiều người. Nó có thể kéo dài nhiều năm; nó có thể kết thúc sớm hay muộn. Điều này chắc chắn sẽ có tác động lớn đến tương lai của tiền điện tử.

ETH
Layer 2
Optimism
Chào mừng tham gia cộng đồng chính thức của Odaily
Nhóm đăng ký
https://t.me/Odaily_News
Tài khoản chính thức
https://twitter.com/OdailyChina
Tóm tắt AI
Trở về đầu trang
Những sự đánh đổi này đáng để thảo luận vì cả hai nền tảng đều nhằm mục đích cung cấp khả năng mở rộng đầy đủ cho Ethereum trong những tháng tới.
Thư viện tác giả
巴比特
Tải ứng dụng Odaily Nhật Báo Hành Tinh
Hãy để một số người hiểu Web3.0 trước
IOS
Android