Gần đây, zkSync và Polygon đều đã ra mắt zkEVM của riêng mình, tạo nên làn sóng phấn khích trong ngành. Điều này cũng khơi mào những thảo luận rộng rãi trong cộng đồng về tính bảo mật và phi tập trung của zkEVM. Trong sự kiện ETHDenver vừa kết thúc, IOSG đã tổ chức một sự kiện tập trung vào bảo mật (Stay SAFU, Security Day), nơi chúng tôi may mắn được mời các dự án hàng đầu trong lĩnh vực Bằng chứng không tri thức tham gia. Họ đã chia sẻ các nguyên tắc bảo mật và phương pháp tiếp cận mới mẻ trong thiết kế và kỹ thuật cơ chế giao thức Bằng chứng không tri thức, cũng như những đánh đổi khác nhau gặp phải trong quá trình thiết kế.
Sau đây là những chia sẻ gốc của các khách mời. Những người tham gia bao gồm:
Queenie Wu, Đối tác IOSG Ventures (Người điều phối);
Alex Gluchowski, đồng sáng lập zkSync;
Ye Zhang, đồng sáng lập và trưởng bộ phận nghiên cứu Scroll ;
Matt Finestone, Giám đốc điều hành của Taiko;
Mikhail Komarov, người sáng lập quỹ Nil;
Brian R, người sáng lập Risc0;
Câu hỏi 1: Bằng chứng không tri thức) tăng cường bảo mật cho hệ thống bạn đang xây dựng như thế nào? Mặt khác, việc triển khai Bằng chứng không tri thức) gây ra những vấn đề bảo mật nào?
[Brian R]
Tôi là Brian Redford, CEO của Risk Zero. Chúng tôi là những nhà phát triển của Risk Zero zkVM, được xây dựng trên Kiến trúc vi mô Risk-V, cho phép thực thi mã tùy ý trong hệ thống ZK. Chúng tôi cũng đang triển khai mạng Layer2 có tên là Bonsai, có thể thực thi mã tùy ý trong ngữ cảnh ZK. Hãy coi nó như một accelerator ZK. Về cách ZK tăng cường bảo mật, tôi nghĩ điều đó phụ thuộc vào ứng dụng cụ thể. Tất nhiên, khả năng thực hiện các phép tính và tạo ra bằng chứng có thể được xác minh ở bất kỳ đâu trên thế giới đã thay đổi hoàn toàn mô hình bảo mật blockchain. Bạn không còn cần phải thực hiện lại các phép tính giống nhau nhiều lần nữa, rồi dựa vào các cơ chế phức tạp (chẳng hạn như cơ chế kinh tế) để đảm bảo an ninh cho toàn bộ hệ thống.
[Mikhail Komarov]
Tôi là Mikhail Komarov, người sáng lập Nil. Chúng tôi cung cấp cơ sở hạ tầng cho các dự án ZK đang triển khai, chẳng hạn như trình biên dịch zk-EVM. Trình biên dịch này biên dịch các ngôn ngữ cấp cao thành các mạch, cho phép mọi phép tính được định nghĩa trong ngôn ngữ cấp cao được chứng minh mà không cần thực thi, chỉ cần các mạch đơn giản. Hơn nữa, chúng tôi đã giới thiệu khái niệm "Thị trường Chứng minh", cung cấp một thị trường đấu thầu phi tập trung cho các dự án muốn tạo ra bằng chứng zkSNARK/STARK. Mỗi nhà phát triển có thể gửi giá thầu cho Bằng chứng không tri thức mà họ cần, sau đó chỉ cần gọi bằng chứng đó trong ứng dụng của họ để có được dịch vụ cần thiết (ví dụ: zkRollup có thể tận dụng Thị trường Chứng minh).
Về cơ bản, chúng tôi là cơ sở hạ tầng mà các nhà phát triển cần. Nó không tự nó nâng cao bảo mật, nhưng nó nâng cao bảo mật tổng thể. Như Brian đã đề cập, nó tăng cường bảo mật bằng cách loại bỏ các giả định về độ tin cậy khiến giao thức chạy trong hoàn cảnh không cần sự tin cậy. Điều quan trọng là giảm thiểu hơn nữa các giả định về độ tin cậy. Đó là cách nó tăng cường bảo mật. Tôi tin rằng nếu các dự án áp dụng Bằng chứng không tri thức, một số sự cố bảo mật xảy ra năm ngoái đã có thể được tránh khỏi.
[Matt Finestone]
Tôi là Matt đến từ Taiko, và chúng tôi là một ZK Rollup tương thích với Ethereum. Chúng tôi nỗ lực tối đa hóa khả năng tương thích Ethereum và EVM. Điều làm nên sự khác biệt của chúng tôi về mặt bảo mật là sự tin tưởng mạnh mẽ vào mô-đun xây dựng, máy trạm và mô hình hợp đồng thông minh Ethereum đã được kiểm nghiệm và chứng minh. Như Mikhail đã đề cập, ZK giảm thiểu các giả định về độ tin cậy hoặc chuyển chúng sang cấp độ giao thức/bằng chứng. "Độ tin cậy" không còn nằm ở những cá nhân có động lực, mà nằm ở toán học, các giao thức và ứng dụng được xây dựng xung quanh các bằng chứng toán học. Có rất nhiều cân nhắc về bảo mật cho ZK Rollup, không chỉ riêng ZK.
Tôi cho rằng chúng ta đang tái sử dụng càng nhiều phần bảo mật của Ethereum càng tốt để giữ cho nó an toàn và ZK sẽ trở thành một hệ thống rất mạnh mẽ theo thời gian và vì nó đã được thử nghiệm thực tế.
[Ye Zhang]
Xin chào mọi người, tôi tên là Ye. Tôi làm việc tại Scroll . Trước tiên, tôi xin giới thiệu ngắn gọn về Scroll. Scroll là giải pháp mở rộng quy mô của Ethereum. Nó tương thích cao với Ethereum. Người dùng có thể tương tác với các ứng dụng và các nhà phát triển có thể triển khai hợp đồng thông minh chỉ bằng cách sao chép và dán mã của họ rồi di chuyển sang Scroll . Nó nhanh hơn và rẻ hơn Ethereum, với thông lượng cao hơn và bảo mật chặt chẽ hơn. Chúng tôi sẽ phi tập trung hệ thống bằng chứng của mình (Mạng chứng minh phi tập trung) để ngăn chặn các điểm lỗi đơn lẻ trong hệ thống bằng chứng. Đây là bước đầu tiên hướng tới phi tập trung của chúng tôi, vì ZK Rollup sẽ phi tập trung trong một thời gian dài sắp tới. Ngay cả khi bạn có niềm tin sâu sắc vào toán học và mật mã, bạn vẫn có thể phải đối mặt với điểm lỗi đơn lẻ này vì bạn dựa vào một trình chứng minh.
Bước đầu tiên phi tập trung là phi tập trung hệ thống chứng minh để làm cho nó đáng tin cậy hơn. Về bảo mật của ZK, tôi cho rằng những diễn giả khác đã thảo luận rằng ZK cung cấp các thuộc tính xác minh công khai rất mạnh mẽ. Về cơ bản, bất kỳ ai cũng có thể thực hiện một phép tính và thực hiện một bằng chứng, sau đó bất kỳ ai cũng có thể xác minh bằng chứng và nhận được sự đảm bảo tương tự. Nếu bạn có hàng triệu nút, mọi người chỉ cần thực hiện lại thuật toán xác minh, thay vì tính toán ban đầu, điều này cũng cho phép mở rộng. Đây là sức mạnh của công nghệ ZK. Đối với những thách thức tiềm ẩn, nếu hệ thống của chúng tôi hoàn toàn dựa vào các phép toán, các lỗi, chẳng hạn như thiếu ràng buộc, có thể nguy hiểm. Đây là lý do tại sao chúng tôi áp dụng nhiều phương pháp để cải thiện bảo mật của mình. Ví dụ: chúng tôi áp dụng phương pháp phát triển do cộng đồng thúc đẩy. Ngay từ ngày đầu tiên, chúng tôi đã mã nguồn mở toàn bộ quy trình phát triển của mình, đã được cả Ethereum và cộng đồng của chúng tôi kiểm tra, thiết lập một tiêu chuẩn cao hơn. Đây là phương pháp chúng tôi giảm thiểu sự tin cậy và cải thiện bảo mật.
[Alex Gluchowski]
Tôi tên là Alex Gluchowski và tôi là CEO của Matter Labs, công ty đứng sau giao thức zkSync. Chúng tôi đang xây dựng zkSync Era Network, một ZK Rollup tương thích với ZK EVM. Chúng tôi đang áp dụng một phương pháp hơi khác so với Rollup tương đương EVM. Chúng tôi cho rằng vào việc áp dụng một phương pháp thực dụng, bắt đầu với một thứ gì đó tương thích để các nhà phát triển có thể dễ dàng chuyển và chuyển các ứng dụng hiện có và khởi chạy từ các công cụ hiện có. Tuy nhiên, hoàn cảnh ZK cuối cùng lại khác. Nếu bạn bị ràng buộc với công nghệ cũ, sẽ rất khó để đạt được công suất tối đa của hệ thống ZK. Điều này rất quan trọng vì sứ mệnh của chúng tôi là mở rộng blockchain lên quy mô thực tế, đưa hàng tỷ người dùng tiếp theo đến với blockchain và tạo ra một mạng lưới giá trị mới. Khi bạn xem xét hàng triệu hoặc thậm chí hàng tỷ người dùng, bạn thực sự muốn giảm chi phí xuống, vì chúng trở nên đáng kể khi tất cả hàng tỷ giao dịch đó tích tụ.
Điều này tác động như thế nào đến cách chúng ta tăng cường bảo mật? Đó là một câu hỏi thực sự thú vị. Khi bạn hỏi làm thế nào để cải thiện bảo mật hoặc bất kỳ yếu tố nào khác, bạn muốn so sánh các lựa chọn thay thế, phải không? Đường cơ sở của tôi là gì? Các lựa chọn thay thế cho việc sử dụng ZK là gì? Các lựa chọn thay thế có thể là các công nghệ mở rộng khác đã có trước ZK Rollup, chẳng hạn như Optimistic Rollup, sidechain, Plasma, v.v. Những điều này đưa ra các giả định mới về độ tin cậy. Nếu mục tiêu của chúng ta là mở rộng quy mô lên một tỷ người dùng và sứ mệnh của chúng ta không chỉ là mở rộng thông lượng mà còn mở rộng giá trị trong khi vẫn duy trì chủ quyền tự chủ, tự quản lý, không cần cấp phép và một hệ thống hoàn toàn không cần sự tin cậy, thì ZK là cách duy nhất để đạt được điều đó.
Câu hỏi 2: Khi so sánh các loại zkEVM khác nhau, chúng tôi thường tập trung vào mở rộng và khả năng tương thích của chúng (Vitalik đã thực hiện một bài so sánh chi tiết: https://vitalik.ca/general/2022/08/04/zkevm.html). Nếu thêm khía cạnh bảo mật, zkSync Era, Scroll và Taiko sẽ so sánh như thế nào với rủi ro bảo mật tiềm ẩn khác nhau có thể phát sinh từ các thiết kế cơ chế khác nhau?
[Alex Gluchowski]
Như diễn giả trước đã đề cập, bạn cần tin tưởng ngầm nhiều thành phần của các hệ thống phức tạp này để đảm bảo bảo mật. Ví dụ, bạn tin tưởng mã do trình biên dịch tạo ra; bạn cho rằng nó đang thực thi logic mà bạn đã lập trình để thực hiện. Tại sao bạn lại tin tưởng nó trong Solidity? Nó không được định nghĩa chính thức, vì vậy bạn chỉ cần tin tưởng rằng trình biên dịch hoạt động chính xác trên các phiên bản. Chúng tôi cho rằng đây là một vấn đề cần được giải quyết. Đó là lý do tại sao chúng tôi đã bắt đầu xây dựng một trình biên dịch dựa trên nền tảng LLVM. Nó hỗ trợ Solidity như một trong những giao diện người dùng của nó và dựa trên nền tảng trưởng thành này, với nhiều công cụ để phân tích mã tĩnh và kiểm tra bảo mật. Phần phụ trợ là máy ảo zkVM của chúng tôi. Chúng tôi cũng có thể hỗ trợ các ngôn ngữ trưởng thành hơn khác đã được sử dụng trong hoàn cảnh bảo mật khác, chẳng hạn như Rust, hoặc các ngôn ngữ mới hơn với các cân nhắc bảo mật bổ sung, chẳng hạn như Move, giúp ngăn chặn các vấn đề bảo mật như chi tiêu trùng lặp. Tóm lại, bất chấp sự phức tạp, chúng ta phải giải quyết vấn đề này từ các cấp độ khác nhau.
[Ye Zhang]
Tôi muốn nói về một số phương pháp khác nhau và bối cảnh . Chúng tôi đang xây dựng một giải pháp tương thích ở cấp độ bytecode EVM. Về cơ bản, chúng tôi tương thích với bytecode EVM. Điều này khác với cách tiếp cận mà zkSync đang thực hiện và chúng tôi tin rằng không nên tin tưởng các trình biên dịch. Đó là lý do tại sao chúng tôi tin tưởng trình biên dịch Solidity. Mặc dù chưa hoàn thiện, nhưng nó tương đối hoàn thiện trong bối cảnh blockchain . Chưa ai từng sử dụng Solidity và LLVM trước đây. Chúng tôi tin rằng đây là một tiêu chuẩn tốt hơn vì nó đã được chứng minh trong thực tế và nhiều hợp đồng thông minh trong DeFi đã được các nhà phát triển Solidity thử nghiệm. Đó là lý do tại sao chúng tôi tin rằng việc tuân thủ tiêu chuẩn trình biên dịch này, tuân thủ tiêu chuẩn trình biên dịch Solidity và tuân thủ các định nghĩa của EVM Yellow Paper, là phương pháp tốt nhất để đảm bảo bảo mật hệ thống. Từ góc độ mạch, chúng tôi không cần phải lo lắng về các vấn đề của trình biên dịch. Chúng tôi không cần phải xây dựng trình biên dịch của riêng mình; chúng tôi chỉ cần tận dụng cơ sở hạ tầng hiện có và chứng minh rằng nó thực thi chính xác.
Chúng tôi muốn tập trung sự phức tạp của việc xây dựng hệ thống chỉ vào việc giải quyết khả năng tương thích mã byte của zkEVM, thay vì xây dựng trình biên dịch và phần phụ trợ được hỗ trợ bởi LLVM. Chúng tôi không muốn phải xây dựng trình biên dịch bổ sung cho zkEVM. Một điều cần cân nhắc nữa là chúng tôi rõ ràng quan tâm đến trải nghiệm của nhà phát triển. Layer2 được xây dựng để mở rộng EVM, vốn đã quá tải lượng lớn mã và ứng dụng Solidity. Chúng tôi muốn các nhà phát triển có thể dễ dàng di chuyển sang hệ thống của chúng tôi mà vẫn đảm bảo tính bảo mật. Đây là lý do tại sao hiện tại chúng tôi không có kế hoạch bổ sung thêm các tính năng phức tạp nào cho EVM.
Việc tuân thủ tiêu chuẩn này cho phép Ethereum thực sự có mở rộng, đồng thời đảm bảo hiệu suất tối ưu và triển khai kịp thời các hệ thống được xây dựng trên nền tảng này. Đồng thời, chúng tôi cũng đang thúc đẩy nhiều triển khai mã nguồn mở khác nhau chính thức Ethereum , bao gồm zkEVM Loại 1 và Loại 2, nhằm giải quyết vấn đề quyền riêng tư và khả năng mở rộng. Chúng tôi đã áp dụng phương pháp mã nguồn mở ngay từ những ngày đầu. Chúng tôi tập trung sâu sắc vào việc phát triển và tiến hóa zkEVM của Ethereum. Chúng tôi dẫn dắt trong đó quá trình phát triển và là một phần của đội ngũ, vì vậy chúng tôi biết chính xác cần bao lâu để toàn bộ hệ thống thực sự sẵn sàng. Đây là lý do tại sao chúng tôi áp dụng phương pháp này: chuẩn bị sản phẩm và tương tác với cộng đồng trước, sau đó mới xem xét cách thức thúc đẩy mục tiêu cuối cùng của Ethereum.
[Matt Finestone]
Đây là hai câu trả lời tuyệt vời. Giải pháp của Taiko và Scroll gần gũi hơn, và chúng tôi chưa giới thiệu trình biên dịch mới. Tôi thích những gì Alex nói: đâu là những lựa chọn thay thế an toàn trong bối cảnh blockchain ? Tôi cho rằng tất cả chúng ta đều đồng ý rằng Ethereum có lẽ là tiêu chuẩn vàng. Chúng tôi đang triển khai theo Sách Vàng, tái sử dụng các thành phần Ethereum thay vì điều chỉnh chúng. Ngay cả các thành phần Ethereum bên ngoài EVM, chẳng hạn như cấu trúc lưu trữ dữ liệu, cũng đã được chứng minh trong thực tế.
Tất nhiên, luôn có những đánh đổi. Alex đã nói về một tỷ người dùng và chi phí cực thấp, cũng như mở rộng giúp duy trì giá trị. Chúng tôi có thể hy sinh nhiều hơn về mặt chi phí, nhưng chúng tôi vẫn tuân thủ các tiêu chuẩn EVM và Ethereum đã được kiểm chứng thực tế. Chúng tôi cũng cân nhắc một số yếu tố mà Ye Zhang đã đề cập liên quan đến tính thực tiễn và tốc độ đưa sản phẩm ra thị trường.
Trong bối cảnh ZK, một số phương pháp tiếp cận rất khó triển khai, chẳng hạn như một số hàm băm hoặc cấu trúc lưu trữ dữ liệu. Chúng tôi không thay đổi những phương pháp này vì không chắc chắn về hiệu quả của chúng, chẳng hạn như thay thế Cây Merkel Patricia bằng Cây Verkle, mặc dù điều này đã nằm trong lộ trình của Ethereum. Chúng tôi đặt niềm tin lớn hơn vào các thành phần đã được thử nghiệm và kiểm chứng thực tế. Sự phức tạp của hệ thống không nằm ở việc tái tạo EVM và các thành phần khác của Ethereum, mà nằm ở việc triển khai đầy đủ ZK với khả năng tương thích EVM. Việc này sẽ mất nhiều thời gian hơn để hoàn thành và chúng tôi sẽ cần phải đánh đổi những yếu tố cần thiết để đạt được khả năng sử dụng lâu hơn so với Scroll . Tuy nhiên, lộ trình triển khai của chúng tôi mang lại sự đảm bảo an ninh cao hơn.
[Mikhail Komarov]
Bản chất đã được kiểm chứng thực tế Ethereum cho phép chúng tôi tái sử dụng tất cả các hệ thống này và giảm thiểu số lượng giả định mới. Tuy nhiên, có một số vấn đề bảo mật mà ít người thực sự cân nhắc, và mục tiêu của chúng tôi là giải quyết chúng. Đầu tiên là bạn phải tin tưởng trình biên dịch. Một vấn đề khác là nếu bạn muốn tương thích hoàn toàn với EVM, chẳng hạn như EVM Loại 1, bạn cần phải triển khai lại thủ công bất kỳ mã lệnh EVM nào trong mạch bằng cách xác định dạng của một biểu thức nhất định dưới dạng mạch trên một miền nhất định. Đây là một quy trình thủ công rất phức tạp và dễ xảy ra lỗi. Chúng tôi đã tự mình thực hiện việc này và làm hỏng mạch của mình, vì vậy chúng tôi biết điều đó không tốt.
Để ngăn ngừa những vấn đề này tái diễn và ngăn ngừa bất kỳ ai mắc phải những sai lầm này, chúng tôi đang nỗ lực loại bỏ giả định bảo mật này bằng cách cho phép mọi người biên dịch mạch bằng một triển khai EVM đã được kiểm chứng thực tế, thay vì phải triển khai lại thủ công tất cả các mã lệnh. Mục tiêu của chúng tôi là biên dịch mạch bằng trình biên dịch LLVM, thay vì triển khai lại thủ công, để giảm thiểu các giả định bảo mật. Đây là một giả định bảo mật khác cần được loại bỏ, và chúng tôi sẽ giải quyết nó cho zkEVM.
[Brian R]
Bạn có thể chạy geth trên một hệ thống như RiscV để giải quyết vấn đề mà Mikhail đã đề cập. Thực ra, chúng tôi chỉ bổ sung hỗ trợ cho Go. Chúng tôi đã xây dựng và thiết kế máy ảo RiscZero, và chúng tôi chọn tập lệnh RiscV một phần vì nó có định nghĩa chính thức và rất nhẹ. Phạm vi bảo mật của các mạch RiscV đã được xác định, và lượng lớn công việc đã được thực hiện để kết hợp phương pháp xác minh chính thức nhằm chứng minh rằng việc triển khai tuân thủ đặc tả RiscV. Chúng tôi tập trung vào việc đảm bảo rằng mật mã trong hệ thống đơn giản này là chính xác, và sau đó chạy EVM trên đó thực sự hoạt động. Tất nhiên, phương pháp này có một nhược điểm về hiệu suất. Ví dụ: mất khoảng 1 phút để chuyển một mã thông báo ERC20.
Câu hỏi 3: Như Alex vừa đề cập, nâng cấp hoặc lựa chọn giải pháp khác là khả thi cho bất kỳ phần nào của hệ thống. Vậy, làm thế nào để đảm bảo nâng cấp của hệ thống và triển khai nó một cách an toàn?
[Brian R]
Vâng, tôi cho rằng nâng cấp là một chủ đề rất quan trọng trong ZK. Theo quan điểm của chúng tôi, khi chưa có mạng lưới triển khai và chưa có lượng lớn giá trị kinh tế đằng sau nó, chúng tôi đã dành lượng lớn thời gian để đảm bảo rằng mình đang xây dựng đúng các khái niệm trừu tượng trong ngăn xếp công nghệ. Chúng tôi có thể chuyển đổi hàm băm, chuyển đổi trường hữu hạn và hệ thống chứng minh, hoặc thêm các công nghệ mới như PLONK vào ngăn xếp. Đây là một lý do khác khiến chúng tôi chọn RiscV làm "bộ lệnh" chính để hỗ trợ, bởi vì nó là một hệ thống trừu tượng rất sạch. Vì vậy, bạn tùy ý thay thế bất cứ thứ gì bạn muốn. LLVM rõ ràng có những đặc điểm rất tương đồng.
[Matt Finestone]
Đúng vậy, nâng cấp là một chủ đề lớn, và chúng ta có thể coi đó là vấn đề của các hệ thống không cần sự tin cậy. Việc triển khai hệ thống có thể có lỗ hổng, gây rủi ro cho người dùng, hoặc tin tưởng vào những người đã xây dựng hệ thống hoặc một số tác nhân nhất định có thể khai thác lỗ hổng. Nâng cấp là tìm kiếm sự cân bằng giữa bảo mật và tính không cần sự tin cậy ở một số cấp độ nhất định. Khi niềm tin vào hệ thống tăng lên, bạn có thể loại bỏ trong đó tác nhân đáng tin cậy. Chúng ta nên rất thận trọng với các tác nhân đáng tin cậy, vì mục đích của những hành động này là loại bỏ chúng. Đối với những hệ thống rất phức tạp này, tốt nhất là can thiệp sớm. Tôi cho rằng Alex và đội ngũ Matter Labs đã cung cấp một số tham khảo tuyệt vời về vấn đề này. Họ có một ủy ban an toàn tốt và cơ chế trì hoãn thời gian.
Vậy nhịp độ nâng cấp phù hợp là gì? Đây là một câu hỏi rất quan trọng. Tôi tự hỏi liệu nhiều người dùng có cảm thấy thoải mái với một hệ thống hoàn toàn không cần tin cậy hay không, vì những hệ thống như vậy thường rất phức tạp và đưa ra nhiều điều mới, hoặc tin tưởng những tác nhân có thiện chí này. Đây là một câu hỏi rất con người và chắc chắn có những giải pháp kỹ thuật, chẳng hạn như đa bằng chứng, có thể là một lựa chọn tốt. Tôi cho rằng có thể sử dụng lại một số thiết kế từ các thành phần tương tự như Optimism . Nếu bằng chứng xác thực của chúng tôi gặp sự cố, việc sử dụng lại việc triển khai Optimistic Rollups sẽ giúp phát triển hệ thống chống gian lận hoạt động trong hoàn cảnh giống Ethereum dễ dàng hơn. Bạn có thể kết hợp các bằng chứng gian lận và bằng chứng xác thực và nếu có bất kỳ phản đối nào, thì nâng cấp hoặc một số loại giải pháp quản trị có thể giải quyết được.
[Mikhail Komarov]
Để tôi giải thích nhé. Tôi vừa dành chút thời gian suy nghĩ về điều này. Tôi lo mình không hiểu câu hỏi, vì tôi đang nghĩ, vấn đề nâng cấp nằm ở đâu? Chỉ cần xây dựng lại mạch. Vậy, vấn đề nâng cấp là gì?
[Ye Zhang]
Theo quan điểm của chúng tôi, trước hết, bạn không thể chỉ biên dịch một mạch mới, vì nó ảnh hưởng đến khóa chứng minh, khóa xác minh và nhiều hợp đồng thông minh trên Chuỗi, vì vậy chắc chắn không thể thực hiện thường xuyên. Chúng tôi đang xem xét phương pháp đa chứng minh, bổ sung các cơ chế như xác minh kép. Có nhiều phương pháp để giải quyết vấn đề này, và như Matt đã đề cập, chúng tôi không xem xét việc tích hợp trực tiếp với các bằng chứng gian lận lạc quan, vì điều đó sẽ khiến tính cuối cùng thậm chí còn lâu hơn. Chúng tôi đang khám phá phương pháp khác và sẽ sớm đưa ra Đề án trong Ethereum Research về cách bổ sung một số đảm bảo bổ sung.
Ví dụ, Justin Drake đã đề xuất sử dụng Intel SGX (một hoàn cảnh TEE) làm biện phương pháp bổ sung, nhằm tăng cường đáng kể khả năng đảm bảo an ninh. Ngoài ra, các phương pháp quản trị khác cũng khả thi, và chúng tôi cho rằng các ủy ban bảo mật và trì hoãn thời gian là những phương pháp đầy hứa hẹn. Chúng tôi cũng đang xem xét vấn đề này. Đây là một sự đánh đổi, và tôi tin rằng hầu hết rollups sẽ mất nhiều thời gian hơn để thực sự khắc phục vấn đề nâng cấp này, vì nâng cấp hệ thống là một quá trình lâu dài. Chúng tôi đang theo dõi và nghiên cứu vấn đề này một cách cẩn thận.
[Alex Gluchowski]
Tôi có thể giải bối cảnh tại sao nâng cấp là một vấn đề quan trọng đến vậy. Ví dụ, với bất kỳ chương trình nào đang chạy trên máy tính, bạn chỉ cần tải xuống phiên bản mới và cài đặt, đúng không? Vấn đề nâng cấp là gì? Vấn đề là trong bối cảnh blockchain , chúng ta đang cố gắng xây dựng các hệ thống không cần sự tin cậy, nhưng trong một số trường hợp, việc nâng cấp có thể làm suy yếu sự tin cậy đó. Đối với Lớp 1, đây không phải là vấn đề. Nếu bạn muốn nâng cấp Ethereum, bạn chỉ cần tải xuống một máy trạm mới, cài đặt nó, và sau đó mọi người sẽ cùng nhau phối hợp fork.
Sau đó, chúng tôi lên lịch fork, ấn định ngày và fork tại một số khối nhất định, để bất kỳ ai không thích lần nâng cấp có thể tiếp tục sử dụng nhánh cũ của phiên bản cũ. Lộ trình nâng cấp này hoàn toàn không cần sự tin cậy. Nó không dựa vào bất kỳ đa số trung thực hay người tham gia đáng tin cậy nào.
Vấn đề phát sinh trong bối cảnh của Layer2. Nếu chúng ta đang xây dựng một Rollup, nó dựa trên hợp đồng thông minh Lớp 1. Hợp đồng thông minh này có thể không thể thay đổi, trong đó một số hàm cố định và khóa xác minh cho các mạch cụ thể đã được tích hợp sẵn. Vấn đề là nếu có lỗi, bạn sẽ không thể làm gì được. Vậy bạn sẽ làm gì nếu gặp lỗi, hoặc nếu bạn muốn sửa lỗi?
Chúng tôi đã tiết lộ một lỗ hổng trong zkSync 1.0 (zkSync Lite) áp đặt khóa thời gian đối với nâng cấp, cho phép đội ngũ nâng cấp Đề án phiên bản mới. Nếu người dùng không thích phiên bản mới, họ có vài tuần để rút tài sản khỏi Lớp 1. Chúng tôi đã có cơ chế Trustless để tạo điều kiện thuận lợi cho việc rút tiền này. Tuy nhiên, vì bị buộc phải áp dụng khóa thời gian này, chúng tôi không thể khắc phục được. Vì vậy, chúng tôi đã đưa ra một giải pháp thỏa hiệp và thành lập cái mà chúng tôi gọi là Hội đồng Bảo mật, một ủy ban độc lập. Chúng tôi đã mời 15 thành viên có tiếng của cộng đồng Ethereum từ nhiều cộng đồng và dự án khác nhau tham gia.
Đội ngũ không kiểm soát hợp đồng; họ chỉ có thể đề xuất nâng cấp, và Hội đồng Bảo an sẽ đưa ra quyết định, có khả năng đẩy nhanh nâng cấp. Tuy nhiên, điều này vẫn chưa tối ưu, vì về mặt lý thuyết, một nhóm cá nhân có thể ngay lập tức cài đặt phiên bản độc hại. Họ có thể không muốn làm điều này, nhưng họ có thể bị một số tác nhân nhất định buộc phải làm như vậy, một khả năng mà chúng ta không thể loại trừ. Do đó, nếu chúng ta muốn tận dụng tối đa Bằng chứng không tri thức và chỉ dựa vào toán học và mã mã nguồn mở, thay vì bất kỳ bên đáng tin cậy nào tham gia vào các quy trình xác minh, cuối cùng chúng ta có thể đạt được một cơ chế hoàn toàn không cần sự tin cậy.
Hiện tại, chúng tôi đang xem xét một phương án tốt hơn, trong đó đội ngũ đề xuất một Đề án nâng cấp có thời hạn, và Hội đồng Bảo mật có thể can thiệp để đề xuất đóng băng các hợp đồng thông minh, sau đó soft fork trên Lớp 1. Điều này đòi hỏi sự phối hợp với Lớp 1, và giao thức Layer2 phải đủ lớn và quan trọng để cộng đồng có thể thực sự fork và cài đặt phiên bản mới. Vì Lớp 1 không thể thực hiện điều này cho mọi giao thức nhỏ, nên nó phải là một giao thức cấp hệ thống lớn, chẳng hạn như trên Ethereum.
Đây là cơ chế tốt nhất hiện có của chúng tôi để tăng cường nâng cấp không cần tin cậy và bảo vệ chúng tôi khỏi các lỗ hổng nghiêm trọng ở lớp đầu tiên. Tuy nhiên, nó vẫn gây ra các vấn đề như tính kịp thời. Nếu sự cố như vậy xảy ra, giao thức sẽ bị tạm dừng trong một khoảng thời gian. Hãy tưởng tượng chúng tôi đã chuyển từ Visa và PayPal sang sử dụng rollups lớn này cho blockchain. Đột nhiên, tài sản người dùng bị đóng băng, không ai có thể thực hiện thanh toán và chúng tôi cần phối hợp nâng cấp trong vài ngày. Đây là một vấn đề rất lớn. Hiện tại, chúng tôi không có giải pháp nào tốt hơn, cũng như không thấy giải pháp nào tốt hơn. Nếu bạn có ý tưởng, vui lòng liên hệ với chúng tôi để chúng ta có thể thảo luận thêm.
Câu hỏi 4: Một từ khóa được nhắc đến lần là "Không cần tin cậy". Như chúng ta đã biết, thành phần quan trọng nhất của hệ thống hiện tại vẫn là tập trung. Chúng ta sẽ phải đối mặt với những thách thức bảo mật nào trong quá trình chuyển đổi từ tập trung phi tập trung?
[Alex Gluchowski]
Tôi cho rằng(Trustless) này sẽ tăng cường bảo mật. Nó sẽ cung cấp cho chúng ta một lớp bảo vệ bổ sung. Đầu tiên, ZK Rollup phải cung cấp bằng chứng xác thực cho mỗi khối, nhưng điều này có thể gây ra vấn đề, ví dụ, nếu chúng ta quên một số ràng buộc nhất định. Hơn nữa, chúng ta cũng cần chữ ký được cung cấp bởi cơ chế đồng thuận Bằng chứng cổ phần, cung cấp một lớp bảo vệ bổ sung. Để xâm nhập hệ thống, kẻ tấn công độc hại trước tiên phải tìm ra lỗ hổng và sau đó phải thông đồng với phần lớn các trình xác thực để khai thác nó.
Điều này tương đối khó xảy ra, vì kẻ tấn công hoặc đã kiểm soát được blockchain hoặc phải mua lượng lớn token. Điều này cho chúng tôi đủ thời gian để những người khác phát hiện ra lỗ hổng tương tự và báo cáo cho Immunefi hoặc một bên thứ ba, cho phép đội ngũ khắc phục. Ngoài ra, chúng tôi cũng có thể chạy đồng thời một vài honeypot, hoàn toàn mở và bất kỳ ai cũng có thể hack để nhận thưởng. Nhìn chung, điều này cung cấp hai yếu tố bảo vệ cho toàn bộ hệ thống. Hơn nữa, chúng tôi có thể bổ sung thêm nhiều yếu tố khác nữa.
Đến thời điểm này, tôi sẽ không tin tưởng một ZK Rollup nào tự nhận là hoàn toàn không đáng tin cậy. Điều đó sẽ cực kỳ rủi ro đối với tôi. Tôi sẽ không đặt một lượng tài sản lớn hơn mức tôi có thể chấp nhận mất vào một ZK Rollup như vậy.
Ví dụ tôi thích nhất là sự cố Boeing 737 Max. Nguyên nhân của vụ tai nạn không phải là vấn đề phần mềm mà họ đang cố gắng đánh lạc hướng sự chú ý, mà là sự phụ thuộc hoàn toàn vô trách nhiệm của họ vào một cảm biến duy nhất trên máy bay. Ngành hàng không có lịch sử lâu đời, với vô số lần cải tiến công nghệ, và việc phụ thuộc vào một hệ thống duy nhất là điều không thể chấp nhận được. Tuy nhiên, trong quá trình sản xuất Boeing 737 Max, họ đã hy sinh thiết kế hệ thống an toàn vì nhiều lý do (chẳng hạn như chi phí và thời gian giao hàng), cuối cùng dẫn đến tai nạn. Do đó, chúng tôi luôn nỗ lực để có ít nhất hai yếu tố an toàn hoàn toàn độc lập để giảm thiểu khả năng xảy ra sự cố.
[Ye Zhang]
Chúng tôi tiếp cận lộ trình phi tập trung ZK Rollup với một tầm nhìn dài hạn. Chúng tôi có những ý tưởng riêng về việc nên phi tập trung hóa Sequencer hay Prover trước, và thậm chí cả cách định nghĩa phi tập trung ZK Rollup. Tôi cho rằng cuối cùng chúng tôi sẽ phi tập trung cả Sequencer và Prover. Tuy nhiên, chúng tôi có sắp xếp hơi khác nhau, và chúng tôi muốn phi tập trung Prover trước. Bảo mật chắc chắn là một lý do chính. Nếu phi tập trung Sequencer trước, trước khi zkEVM hoàn toàn trưởng thành và mạnh mẽ, nếu ai đó thực sự phát hiện ra lỗ hổng và gửi bằng chứng sai, thì có khả năng Sequencer sẽ chấp nhận và tạo ra một khối, có khả năng gây hại cho hệ thống.
Do đó, ban đầu chúng tôi sẽ duy trì một bộ sắp xếp tập trung. ZkEVM dễ bị tấn công và là một hệ thống rất phức tạp. Do đó, chúng tôi hy vọng sẽ duy trì quyền kiểm soát tập trung sắp xếp, ít nhất là trong giai đoạn đầu, để đảm bảo việc tạo khối chính xác và hiệu quả.
Một lý do khác để phi tập trung là nhiều công ty phần cứng đang tìm cách làm cho zkEVM hiệu quả hơn. Nếu chúng tôi cam kết phi tập trung Prover, họ sẽ tham gia vào việc tối ưu hóa mã hệ thống. Chúng ta đều biết rằng ZK ASIC có thể mất hơn một năm để phát hành. Nếu chúng tôi phi tập trung Prover trước, họ sẽ có động lực hơn để xây dựng cho hệ thống của chúng tôi, giúp nó hiệu quả hơn. Phi tập trung Sequencer là điều chúng tôi dự định thực hiện sau.
Có một yếu tố phức tạp hơn cần xem xét ở đây. Nếu Người chứng minh và Người sắp xếp được phân công vào hai nhóm khác nhau, cơ chế khích lệ cần được thiết kế rất cẩn thận. Ví dụ, tỷ lệ phần thưởng được phân bổ cho hai bên phải hợp lý và khích lệ.
Ngoài ra, chúng tôi còn có một số biện pháp bảo mật khác. Ví dụ, phương pháp chúng tôi đang xây dựng là mã nguồn mở, và chúng tôi đang tiến hành kiểm toán bảo mật nội bộ, chứ không chỉ kiểm toán bên ngoài. Chúng tôi có một đội ngũ bảo mật rất mạnh. Chúng tôi cung cấp nhiều khoản tài trợ khác nhau để khuyến khích sự tham gia nhiều hơn vào việc xây dựng các giải pháp bảo mật, chẳng hạn như các công cụ như xác minh chính thức. Đội ngũ của chúng tôi cũng đã tìm thấy các lỗ hổng trong các mạch ConsenSys ZKEVM và Aztec. Chúng tôi đang nỗ lực cải thiện bảo mật cho toàn bộ hệ sinh thái.
[Matt Finestone]
Taiko có thể đối mặt với thách thức này sớm hơn. Mặc dù cả hai đều có một mức độ phi tập trung nhất định, nhưng chúng tôi thực sự đang có kế hoạch duy trì cùng một cách tiếp cận như Ethereum, bao gồm EVM, lịch trình gas và trie trạng thái. Chúng tôi cũng đang xem xét Ethos và các trình đề xuất trình tự và trình chứng minh phi tập trung khác (những gì chúng tôi gọi). Trong mạng thử nghiệm đầu tiên của chúng tôi cách đây vài tháng, khoảng 2.000 cá nhân hoặc địa chỉ độc lập đã đề xuất một khối mà không được phép. Mặc dù có thể có một số khối độc hại, nhưng đây cũng là lời hứa về phi tập trung. Tôi không cho rằng đây là phi tập trung gia tăng, mà là sự gia tăng hiệu quả, vì bạn phải hy sinh một số hiệu quả. Những người đề xuất có thể tạo các khối trùng lặp, dẫn đến một số giao dịch dư thừa và trả giá không gian khối có giá trị được trả cho Lớp 1 bằng ETH. Một số sẽ được hoàn lại tiền, trong khi những người khác sẽ chỉ đơn giản là bỏ qua.
Việc đạt được phi tập trung ngay lập tức trong mạng thử nghiệm sắp tới là không thực tế. Việc chứng minh không cần cấp phép rất khó khăn trong hoàn cảnh mạng thử nghiệm do các cuộc tấn công Phù thủy, nơi mọi người có thể lấp đầy các khối được đề xuất bằng thư rác, và người chứng minh phải tiêu tốn tài nguyên tính toán thực sự để chứng minh chúng, nhưng không có thu nhập thực tế.
Do đó, chúng tôi sẽ sử dụng Permissioned Proposer, cho phép bất kỳ Prover phi tập trung gửi khối và nhận phần thưởng tương ứng. Điều này rất quan trọng. Hơn nữa, nếu hệ thống gặp sự cố và Prover gửi bằng chứng xác thực, đồng thời một bằng chứng không nhất quán cũng được gửi, hợp đồng thông minh sẽ nhận biết điều này và dừng lại. Nó sẽ hiểu tại sao có hai bằng chứng xác thực chính xác trên các khối khác nhau và ngay lập tức dừng quá trình, do đó gây ra độ trễ thời gian. Như Alex đã đề cập, hiện tại chúng ta không thể tự tin vào một triển khai hoàn toàn không cần cấp phép và không cần sự tin cậy; chúng ta phải cố gắng đạt được sự cân bằng.
[Mikhail Komarov]
Chúng tôi đã xem xét vấn đề này ngay từ đầu. Một số người ban đầu tiếp cận vấn đề từ phương pháp xuống, quyết định tạo một Rollup rồi sau đó xem xét thứ tự phi tập trung, chẳng hạn như phi tập trung rồi phi tập trung Prover, từng bước một. Ngược lại, chúng tôi lại áp dụng một phương pháp khác: tiếp cận vấn đề từ dưới lên.
Đầu tiên, chúng tôi xây dựng một mạng lưới Prover phi tập trung để tập trung tỷ lệ băm mà không cần cấp phép. Sau đó, chúng tôi đã nghiên cứu việc bổ sung một Sequencer vào mạng lưới Prover. Điều này đòi hỏi sự tích hợp chặt chẽ với mạng lưới Prover, đặc biệt là một mạng lưới phi tập trung đã phát triển hoàn thiện. Điều này liên quan đến phí chứng minh bổ sung và độ phức tạp trong giao tiếp, vì vậy Sequencer phải được tích hợp chặt chẽ với mạng lưới Prover để đảm bảo hiệu quả. Hệ thống chúng tôi phát triển có thể đóng vai trò là cơ sở hạ tầng cơ bản cho ZK Rollup.
Để đảm bảo mọi hoạt động tạo bằng chứng đều được khích lệ nhằm đẩy nhanh quá trình hoàn thành, cải thiện chất lượng và duy trì bảo mật, chúng tôi đã giới thiệu một thị trường bằng chứng để quản lý việc tạo và sắp xếp tất cả các bằng chứng. Đồng thời, chúng tôi vẫn duy trì tính phi tập trung và không cần cấp phép của hệ thống này. Phương pháp này giải quyết vấn đề từ dưới lên, thay vì từ trên xuống.
[Brian R]
Tôi cho rằng phương pháp của chúng tôi khác biệt đáng kể so với các mạng lưới khác. Nó tương tự như thị trường chứng minh mà đội ngũ Nil đang xây dựng, nhưng chúng tôi đang áp dụng một cách tiếp cận không cần quá tin cậy. Thay vì tập trung vào việc sắp xếp, chúng tôi tập trung vào việc làm cho hệ thống chứng minh mạnh mẽ hơn cho nhiều phép tính khác nhau. Phương pháp này đơn giản hóa rất nhiều sự phức tạp và giúp chúng tôi đưa phần lớn phép tính ra thị trường nhanh nhất có thể.
Chúng tôi muốn giảm bớt rào cản gia nhập cho các nhà phát triển, cho phép họ xây dựng bất kỳ ứng dụng nào họ muốn trên Ethereum hoặc bất kỳ hệ thống nào và có lớp điện toán cơ bản phi tập trung này với Bằng chứng không tri thức để đảm bảo tính chính xác của các phép tính.
Câu hỏi 5. Khán giả: Trong Algorand , có một kỹ thuật gọi là Vẽ Trạng thái (State Painting). Ý tưởng cơ bản của nó là rút trạng thái từ một blockchain đồng thuận và "vẽ" nó lên một blockchain khác. Kỹ thuật này thiên về blockchain liên Chuỗi, cũng sử dụng Bằng chứng không tri thức. Ở Layer2 , sự đồng thuận của hệ thống dựa trên sự đồng thuận của Lớp 1. Điều này có làm ảnh hưởng đến bảo mật Layer2 không?
[Alex Gluchowski]
Trong quá trình triển khai ZK Rollups , luồng tài sản giữa Lớp 1 và Layer2 hoàn toàn không cần tin cậy, Layer2 kế thừa tính bảo mật của Lớp 1. Việc chuyển giao tài sản giữa Layer2 cũng hoàn toàn không cần tin cậy nếu được thực hiện thông qua cầu nối gốc Lớp 1 của Ethereum. Tuy nhiên, nếu không được thực hiện thông qua Lớp 1, tính bảo mật của việc chuyển giao phụ thuộc vào phương thức Chuỗi chéo được sử dụng để triển khai cầu nối.
Trong zkSync, chúng tôi đang triển khai một thứ gọi là Hyperchain. Cụ thể, chúng tôi sẽ xây dựng nhiều Chuỗi được vận hành bởi cùng một mạch, vẫn được kết nối bằng một cầu nối trên Ethereum. Hyperchain sẽ cung cấp các giao dịch miễn phí, hoàn toàn không cần tin cậy và rất rẻ từ Chuỗi Chuỗi bất kỳ Chuỗi nào khác. Điều này cực kỳ quan trọng khi chúng ta nói về việc đưa hàng trăm triệu, thậm chí hàng tỷ, người dùng đến với blockchain.
Trong tương lai, hàng nghìn tỷ giao dịch sẽ không thể chạy trên một hệ thống hoặc cơ chế đồng thuận duy nhất. Chúng sẽ phải chạy trên nhiều hệ thống đồng thuận khác nhau, chẳng hạn như phân mảnh, Chuỗi ứng dụng độc lập, v.v. Đồng thời, chúng ta cần đảm bảo rằng Chuỗi khác nhau này có thể kết nối được và chi phí giao tiếp thấp.
Ví dụ, giống như cách chúng ta sử dụng hệ thống email ngày nay, người dùng có thể dễ dàng giao tiếp qua nhiều hệ thống email khác nhau. Đây chính là điều chúng tôi hy vọng đạt được với Hyperchain. Bên cạnh việc kế thừa hoàn hảo tính bảo mật của Lớp 1, giao tiếp xuyên Chuỗi hiệu quả và không cần tin cậy, Hyperchain còn có thể đạt được chi phí cực thấp thông qua các bằng chứng đệ quy.
