Quan điểm | Làm thế nào để hiểu "chuỗi bên"?
Tuyển chọn TechFlowTuyển chọn TechFlow
Quan điểm | Làm thế nào để hiểu "chuỗi bên"?
Trước đây, sidechain là giải pháp duy nhất khả dụng trong khi vẫn duy trì mức độ nhất định về khả năng tổ hợp và tương tác với Ethereum. Hiện nay, khi các giải pháp mở rộng Layer-2 khác đã trưởng thành, đã đến lúc cần xem xét cách thức kết hợp hiệu quả hơn giữa sidechain và các giải pháp khác.
Chuyên sâu báo cáo Web3Tác giả: barryWhiteHat
Dịch: A KIẾM
Lời mở đầu
Lớp 2 (Layer-2) ngày càng quan trọng đối với Ethereum và điều này đã trở thành sự đồng thuận chung.
Tuy nhiên, cụm từ “Lớp 2” là một nhãn hiệu không chính xác.
Khi một số người nói đến “Lớp 2”, họ chỉ đơn giản muốn ám chỉ “những thứ không nằm trên Lớp 1 của Ethereum”.
Nhưng thực tế, cách mà các giải pháp tương tác với Lớp 1 Ethereum lại cực kỳ quan trọng. Các giải pháp khác nhau dù cùng mang danh “Lớp 2” vẫn có thể sở hữu những đặc tính hoàn toàn khác biệt.
Có thể tranh luận rằng “Lớp 2” nên được dành riêng cho những thứ có thuộc tính nhất định (ví dụ như chúng ta đều đồng ý rằng một hệ thống triển khai trên AWS không phải là Lớp 2, nhưng cũng có một vài dự án dù có mức độ đảm bảo an ninh tương tự nhưng vẫn được xem là Lớp 2). Tuy nhiên, đó không phải chủ đề tôi muốn bàn ở đây.
Ở đây, tôi muốn thảo luận về các thuộc tính của sidechain (chuỗi bên).
Sidechain là gì?
Ý nghĩa cơ bản của sidechain là: một hệ thống trong đó một nhóm máy xác thực (validator) gửi trạng thái mới nhất của một chuỗi lên một hợp đồng thông minh trên chuỗi chính, và nhờ vậy tiến triển hệ thống. Những điểm kiểm tra (checkpoint) trạng thái này có thể được một hợp đồng cầu nối (bridge contract) sử dụng để hỗ trợ việc gửi tiền và rút tiền của người dùng.
Thông thường, giữa nhóm máy xác thực này sẽ có một quy trình bầu chọn lãnh đạo để quyết định ai là người tạo khối sidechain tại từng thời điểm; ví dụ như thuật toán PoA (Proof-of-Authority) hoặc thuật toán PoS.
(Chú thích người dịch: Từ định nghĩa này có thể thấy rõ, tác giả đang nói tới các sidechain không được thiết kế cơ chế đảm bảo tính hợp lệ trên chuỗi chính; theo định nghĩa rộng rãi hiện nay về “sidechain”, thì chủ đề tác giả đang bàn là một tập con của khái niệm sidechain tổng quát; tuy nhiên, khái niệm “sidechain” nguyên thủy – tức là khái niệm sidechain hẹp – đúng như tác giả mô tả ở đây. Việc hiểu "sidechain" là một thuật ngữ chuyên biệt hay chấp nhận nghĩa mở rộng hoàn toàn tùy thuộc vào người đọc.)
Sidechain cũng đóng vai trò quan trọng trong hệ sinh thái Ethereum. Trước khi các nhà nghiên cứu phát triển ra các giải pháp tốt hơn, chúng là các phương án tạm thời nhằm cải thiện khả năng mở rộng và tính khả dụng. Các sản phẩm như xDai đã làm nổi bật nhu cầu về trải nghiệm người dùng tốt hơn và phổ biến hóa điều đó.
Tuy nhiên, sidechain không sở hữu mức độ an toàn mà cộng đồng Ethereum rộng lớn mong đợi. Điều này không có nghĩa là không bao giờ nên sử dụng sidechain.
Nếu mọi người biết rõ tình hình và vẫn muốn dùng, đó là lựa chọn của họ, và có thể là đáng giá.
Nhưng nếu mọi người không biết rõ, thì đó là nguy hiểm.
Bài viết này nhằm cung cấp thêm thông tin. Nếu tất cả mọi người đã hoàn toàn hiểu rõ các đặc tính này rồi, thì việc tôi viết thêm một bài nữa cũng chẳng hại gì. Nhưng nếu bài viết này giúp ai đó nhận ra hiểu lầm của mình, thì coi như đã làm được điều tốt.
Vậy thì sidechain thiếu những đặc tính an toàn nào? Gần như tất cả các sidechain đều không thể cung cấp:
-
Kháng kiểm duyệt (censorship resistance)
-
Tính dứt khoát (finality)
-
Đảm bảo quyền sở hữu tài sản
Nếu bạn cần tất cả các đặc tính trên, bạn có lẽ nên tìm giải pháp thay thế khác ngoài sidechain. Tất nhiên, cũng có thể cải thiện các biểu hiện cụ thể của sidechain trên các khía cạnh này trong khuôn khổ kiến trúc cốt lõi của nó. Tôi nghĩ một cuộc thảo luận mở sẽ có lợi cho tất cả mọi người.
Kháng kiểm duyệt
Rõ ràng, khả năng kháng kiểm duyệt của sidechain yếu hơn so với blockchain (được thiết kế tốt). Bằng không, chúng ta đã chẳng cần blockchain làm gì. Nhưng hãy đào sâu hơn. Giả sử một sidechain có N máy xác thực, và chỉ cần M máy xác thực đồng thuận là có thể kiểm duyệt bất kỳ giao dịch nào, vậy thì chỉ cần (N-M) máy xác thực liên kết với nhau là có thể kiểm duyệt một khối. Điều này dẫn đến một nghịch lý thú vị: làm cho việc kiểm duyệt giao dịch khó hơn sẽ khiến việc kiểm duyệt khối dễ dàng hơn. Vì cả hai kiểu kiểm duyệt đều là điều tồi tệ, nên về bản chất, sidechain không thể đạt được khả năng kháng kiểm duyệt mạnh mẽ (chú thích người dịch: lập luận ở đây như sau, nếu chỉ cần M máy xác thực không đồng ý thì hệ thống không thể tạo khối, thì hiển nhiên, chỉ cần M máy xác thực là có thể kiểm duyệt một giao dịch bằng cách từ chối tạo khối; nhưng điều này cũng có nghĩa là chỉ cần N-M máy xác thực đồng ý, họ có thể tự do tạo khối, luôn tạo khối chứa nội dung khác mà không tạo khối bị phản đối, thậm chí cùng nhau biến mất). Lo ngại này vẫn tồn tại khi sử dụng PoS, thậm chí còn tệ hơn vì việc tính trọng số khối theo cổ phần có thể làm giảm số lượng thực thể độc lập cần thiết để đạt ngưỡng (ngay cả trong trường hợp lý tưởng nhất, khi cổ phần phân bổ hoàn toàn đều, thì cũng chỉ bằng trường hợp không dùng PoS, chứ không tốt hơn).
Đảm bảo tính sẵn có dữ liệu (data availability guarantee)
Giả sử chỉ cần (N-M) máy xác thực là có thể tạo một khối mới. Giả sử rằng tất cả các máy xác thực khác cần có toàn bộ dữ liệu trạng thái để xác minh trạng thái mới. Vậy thì, nếu (N-M) máy xác thực là ác ý, họ có thể:
-
Tạo một khối mới
-
Từ chối chia sẻ dữ liệu khối với các máy xác thực trung thực
-
Về bản chất, loại bỏ M máy xác thực trung thực khỏi quá trình đạt đồng thuận, từ đó kiểm soát hoàn toàn toàn bộ hệ thống
Xác suất xảy ra tình huống này là bao nhiêu? Rõ ràng cần chi tiết cụ thể hơn mới đưa ra kết luận, nhưng ta có thể bắt đầu suy nghĩ như sau: động lực nào khiến một máy xác thực hợp lý muốn chia sẻ dữ liệu với người khác? Trong cơ chế PoA truyền thống, việc không chia sẻ có thể gây tổn hại đến uy tín. Tuy nhiên, cơ chế uy tín thực tế khó hoạt động, vì thật sự không có cách nào chứng minh dữ liệu bị giữ lại, trừ khi người khác đặt toàn bộ dữ liệu lên chuỗi. Nghe giống giải pháp optimistic rollup? Đúng vậy, chính xác như vậy. Điều này cũng có nghĩa là, một sidechain có tính an toàn tốt hơn về bản chất sẽ “thoái hóa” thành optimistic rollup. Trong hầu hết các giải pháp sidechain, các máy xác thực nhận được phần thưởng dưới một hình thức nào đó vì công việc của họ. Đối với máy xác thực trung thực, phần thưởng được chia đều giữa N máy xác thực. Đối với máy xác thực ác ý, cùng một lượng phần thưởng chỉ được chia cho M = N-(N-M) máy xác thực, do đó các máy xác thực hoàn toàn có động lực để không chia sẻ trạng thái cập nhật với người khác (chú thích người dịch: phép tính ở đây có vẻ sai). Ở đây tồn tại một vấn đề căn bản: rất khó phân biệt một cuộc tấn công làm mất tính sẵn có dữ liệu (data availability attack). Với các máy xác thực trung thực, rất khó xác định liệu có ai đang tấn công hay đơn thuần là mình gặp vấn đề đồng bộ.
Tính dứt khoát (Finality)
Giả sử quy trình chuyển đổi trạng thái như sau: state1 => state2 => state3, mỗi lần chuyển đổi cần một số giao dịch được thực thi trên trạng thái hiện tại để thay đổi trạng thái. Tính dứt khoát nghĩa là một khi giao dịch đã được thực thi, thì không thể đảo ngược. Các điểm kiểm tra (checkpoint) của sidechain, sau khi đạt đồng thuận bởi các máy xác thực sidechain, được gửi lên chuỗi khối Ethereum và được cố định nhờ cơ chế đồng thuận của Ethereum. Một số người có thể cho rằng tính dứt khoát của sidechain tương đương với tính dứt khoát của Ethereum; muốn hoàn tác (rollback) khối sidechain thì cũng phải hoàn tác khối Ethereum. Nhưng đây là sự hiểu lầm hoàn toàn. Bởi vì tính dứt khoát nghĩa là không thể hoàn tác giao dịch, chứ không phải là không thể thay thế trạng thái cũ bằng trạng thái mới. Chỉ cần (N-M) máy xác thực đồng thuận, họ có thể thực hiện chuyển đổi trạng thái như sau: state1 => state2 => state1 (dùng state1 thay thế state3, tức là hoàn tác state2 vốn đã được coi là dứt khoát, mà không cần Ethereum chính chủ phải hoàn tác gì cả).
Đảm bảo quyền sở hữu tài sản trên sidechain
Giả sử trạng thái hiện tại là state1={Alice:1000,Bob:0}, tức là Alice có 1000 đơn vị, Bob thì không có gì. Nếu Bob là ác ý và kiểm soát (hoặc có thể hối lộ hiệu quả) đa số máy xác thực POA, anh ta có thể làm gì? Anh ta có thể thực hiện chuyển đổi trạng thái: state1 => state2, trong đó state2={Alice:0,Bob:1000}, tức là đánh cắp toàn bộ tiền của Alice và chuyển cho Bob. Do đó, khả năng phòng thủ của sidechain bị suy yếu thành: sẽ không có (N-M) máy xác thực đồng ý thực hiện chuyển đổi trạng thái bất hợp pháp như vậy. Đây là điều đã được biết đến rộng rãi (ít nhất tôi tin như vậy), nhưng tôi nghĩ vẫn cần nhắc lại. Niềm tin của bạn vào một sidechain chỉ giới hạn ở niềm tin rằng đa số các máy xác thực sẽ không làm điều này. Phần lớn các phân tích an ninh đối với sidechain nên tập trung vào điểm này. Có thể vẫn có một vài người nào đó mà bạn có thể tin tưởng ở mức độ nào đó. Cũng giống như nhiều người trong chúng ta (tin tưởng) các nhà cung cấp dịch vụ tập trung vì nhiều lý do khác nhau. Đôi khi sự đánh đổi này là đáng giá. Điều quan trọng là bạn phải nhận thức rõ rằng đây là một sự đánh đổi.
Vấn đề khi dùng quy trình quản trị như biện pháp phòng thủ
Có một lập luận cho rằng: “Chúng ta có thể dùng quy trình quản trị để giải quyết tất cả các vấn đề nêu trên”. Cách tiếp cận này có điểm yếu, vì toàn bộ hệ thống sẽ thoái hóa thành một quy trình quản trị. Lý do khiến tôi đặc biệt lo ngại về lập luận này là nó ngụ ý rằng các thuộc tính khác của sidechain chỉ là sân khấu biểu diễn (vậy thì, tại sao và khi nào chúng ta cần những thuộc tính như vậy?). Ví dụ, nếu quy trình quản trị là biện pháp cuối cùng ngăn chặn các vấn đề nêu trên, thì có nghĩa là PoS, PoA, v.v., đều không còn quan trọng nữa. Quy trình quản trị của hệ thống mới chính là PoA thực sự. Và rõ ràng, chính quy trình quản trị của hệ thống cũng có thể bị tấn công theo đúng cách thức tương tự.
Thuộc tính của sidechain có thể đặc biệt hữu ích ở đâu?
Ngoài một số thuộc tính bổ sung của sidechain, ví dụ như thời gian khối nhanh hơn (do đó trải nghiệm người dùng tốt hơn), thực sự có một vài trường hợp mà đặc điểm của sidechain có thể phát huy mạnh mẽ. Ví dụ:
-
Bạn thực sự muốn chỉ cần N-M máy xác thực là có thể thực hiện mọi chuyển đổi trạng thái. Một ứng dụng doanh nghiệp yêu cầu quyền kiểm soát cao là một ví dụ điển hình.
-
Trường hợp M=0, tức là N máy xác thực có thể thực hiện mọi chuyển đổi trạng thái. Ví dụ như một trò chơi bốn người chơi. Tuy nhiên vấn đề là, chỉ cần một máy xác thực là có thể tắt chuỗi này.
Kết luận
Trước đây, sidechain là giải pháp duy nhất khả dụng nhằm duy trì mức độ nhất định về tính kết hợp (composability) và khả năng tương tác với Ethereum.
Hiện nay, khi các giải pháp mở rộng lớp 2 khác ngày càng trưởng thành, đã đến lúc cần xem xét cách thức để sidechain kết hợp tốt hơn với các giải pháp khác. Có một vài thuộc tính mà sidechain nên tích hợp:
-
Thực hiện di chuyển quy mô lớn miễn phí, đảm bảo người dùng không bị kẹt do chi phí và không thể rút tiền.
-
Thay thế cơ chế bầu chọn lãnh đạo bằng các giải pháp khác có khả năng kháng kiểm duyệt mạnh hơn (PoS có thể là một hướng đi sai lầm. Xem bài viết này)
-
Cần một bộ điều phối để xử lý sự khác biệt giữa hai trạng thái trên chuỗi.
-
Thêm bằng chứng lỗi (fault proof) để ngăn chặn các chuyển đổi trạng thái bất hợp pháp.
Khi công nghệ optimistic rollup và optimistic VM ngày càng trưởng thành, phạm vi các lựa chọn đánh đổi của các dự án cũng sẽ thay đổi. Vì vậy, đây là thời điểm tốt để suy ngẫm lại về các thuộc tính của sidechain và các sự đánh đổi liên quan.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
