Tôi thấy một người bạn phàn nàn về việc @zkSync luôn ngừng hoạt động. Trên thực tế, gọi nó là "không hoạt động" là một sự cường điệu. Nói chính xác thì nó có nghĩa là "sản xuất khối không ổn định". Về cơ bản, giao dịch do Sequencer gửi cuối cùng đã được xác minh vào thời điểm không ổn định, nhưng người dùng ở khía cạnh tương tác không rõ ràng vì thiết kế Xác minh của zkSync có độ trễ xác nhận. Sự bất ổn cũng sẽ được giảm bớt trong giai đoạn phân quyền trong tương lai. Tôi đã vẽ biểu đồ luồng kỹ thuật và thảo luận với mọi người. 🧵

Lý do khiến một số người dùng cảm thấy "thời gian ngừng hoạt động" có thể là do giao dịch không thành công do tính tương thích của một số DApp nhất định và chuỗi cơ bản. Xét cho cùng, việc phát triển DApp trên zkSync là rất khó khăn. Tôi quan sát thấy từ trình duyệt chính thức rằng việc thay đổi trạng thái từ Cam kết sang Đã xác minh mất khoảng 30 phút đến 1 giờ. Trong những ngày đầu, để bảo mật hệ thống của chuỗi L2, việc tồn tại khoảng thời gian như vậy là điều bình thường. Bài viết này tập trung vào khoa học phổ biến về logic cơ bản của công nghệ zkSync.

Như workflow đã chỉ ra, zkSync hoạt động theo các bước sau:

1）Người dùng gửi giao dịch hàng loạt đến bộ sắp xếp Sequencer thông qua relay;

2）Sequencer chịu trách nhiệm sắp xếp, tổng hợp và đóng gói giao dịch thành Merkle tree;

3）zkPorter sẽ tạo chứng minh zk-SNARK từ Merkle tree;

4）Chứng minh zk-SNARK được relay đến các Validators của L2 và chuỗi chính L1 để tạo Commit Hash;

5）Validator chịu trách nhiệm xác minh tính chính xác của chứng minh zk-SNARK, sau khi không có sai sót sẽ gửi cho hợp đồng thông minh L1 để tạo Verify Hash;

6）Hợp đồng thông minh zkSync trên L1 kiểm tra tính tương thích của Commit Hash và Verify Hash;

7）Sau khi khớp thành công, tạo giao dịch đã xác minh và cuối cùng đưa lên chuỗi;

8）Nếu khớp không thành công, Commit Hash ban đầu sẽ bị hủy, Sequencer sẽ gửi lại batch và làm lại quy trình.4/n

Cần nhấn mạnh rằng, zkSync đã áp dụng “gửi hai giai đoạn (2PC)”, thông qua việc kiểm tra hash Commit và Verify Hash ở hai giai đoạn cuối cùng xác định lô giao dịch hợp pháp. Cách làm này vừa đảm bảo tính nhất quán an toàn của dữ liệu trong quá trình vận hành của hệ thống, theo cách hiểu cá nhân của tôi, cũng thể hiện một tư tưởng phi tập trung làm cho hai thành phần hệ thống Sequencer và Validator ràng buộc lẫn nhau, xứng đáng được khen ngợi.

Workflow của zkSync chủ yếu có bốn vai trò: Relay, Sequencer, zkPorter, Validator, trong quá trình phối hợp sẽ có nhiều “yếu tố không ổn định”. Có thể tóm tắt là sự ổn định chức năng của các nút, sự ổn định hợp tác của các nút, và độ phức tạp của thuật toán và giao thức cơ sở. Bất kỳ sai sót nào trong một khâu đều có thể dẫn đến độ trễ trong việc tạo khối. Sự cố kỹ thuật của Arbitrum Sequencer là một ví dụ điển hình, thách thức mà zkSync phải đối mặt sẽ còn nhiều hơn.

Về độ phức tạp của thuật toán, đây là số phận của chuỗi zkSync, cần các nhà phát triển trong hệ sinh thái nỗ lực vượt qua. Và về sự ổn định của trí tuệ và hợp tác của các nút, tôi nghĩ rằng trong tương lai, khi giai đoạn phi tập trung đến, sẽ có những cải thiện hiệu quả. Lý do cũng đơn giản:

1）Nhiều nút phân tán, có thể tránh được sự không ổn định của mạng do lỗi điểm đơn, hệ thống có tính khả thi cao;

2）Cơ chế khuyến khích token phân tán có thể cung cấp động lực cho các nhà phát triển duy trì sự ổn định của các nút.

Hãy suy nghĩ từ một góc độ khác, thời gian xác minh dài trong giai đoạn đầu của hệ sinh thái không phải là vấn đề, có thể nâng cao hiệu quả an toàn của chuỗi, tránh việc một số nút trong hệ thống làm điều xấu. Tóm lại, nếu làm rõ toàn bộ quy trình vận hành của zkSync, hiểu thêm về độ phức tạp công nghệ của layer 2 và cơ chế “đặc biệt” được thiết kế cho an toàn, có thể củng cố niềm tin vào lĩnh vực công nghệ L2. Chào mừng mọi người chia sẻ, luôn sẵn sàng DM tôi, cùng nhau trao đổi sâu sắc và học hỏi về zkSync.