Chuyển tiếp Tiêu đề Gốc: Blockspace Thiết kế: Tương lai của Môi trường Thực thi

Trong chín năm kể từ khi Ethereum ra mắt blockchain phi tập trung, có thể lập trình đầu tiên, tiền điện tử đã đối mặt với nhiều chướng ngại về việc mở rộng ứng dụng phi tập trung đến hàng tỷ người dùng. Và để phát triển các giải pháp mở rộng để giải quyết vấn đề này, ngành công nghiệp tiền điện tử đã liên tục tài trợ và phát triển loại blockchain hoàn toàn mới để giải quyết “vấn đề về hiệu suất.”

Tuy nhiên, “vấn đề về hiệu suất” đã được định nghĩa và định lượng kém cỏi. Những biểu tượng tổng hợp như “giao dịch mỗi giây” đã đóng gói gọn gàng những gì thực sự là sự so sánh giữa táo và cam giữa các giao dịch mà không đòi hỏi công việc tính toán tương đương. Sự thiếu sáng suốt trong các chỉ số này cũng che khuất khả năng đánh giá tác động độc lập của các thành phần của blockchain đối với hiệu suất, làm lạc hướng chúng ta khỏi việc tiếp cận nguyên tắc để xác định các tập hợp các tối ưu hóa mà chúng ta có thể thực hiện để giải quyết các vấn đề có sự phụ thuộc cao.

Mặc dù có sương mù này, chúng tôi đã thấy những cải tiến đáng tin cậy, bền vững về khả năng mở rộng blockchain diễn ra trong vài năm qua. Khi Ethereum tiến qua con đường roadmap tập trung vào rollup, một làn sóng mới của rollups, coprocessors,sẵn sàng dữ liệu(DA) layers, và các L1 cạnh tranh đang nổi lên - mỗi cái với những lựa chọn thiết kế độc đáo để cung cấp môi trường hoạt động hiệu suất cao hơn cho các nhà phát triển xây dựng dapps có khả năng mở rộng, thân thiện với người dùng.

Hôm nay, việc giới thiệu EIP4844 và các lớp DA thay thế đã giảm thiểu được chướng ngại vật DA quan trọng. Mặc dù đây là một cột mốc quan trọng, dấu hiệu cho thấy các chướng ngại vật quan trọng khác cần được giải quyết. Tháng trước, Cơ sở collected 1,57 triệu USD trong các phí giao dịch trong một ngàytrong khi chỉ trả $5K chi phí sẵn có dữ liệu cho Ethereum. Điều này cho thấy rằng công việc tính toán cần thiết để xác nhận và xử lý cập nhật trạng thái vẫn là một rào cản quan trọng và một cơ hội để cải thiện.

Bài viết này sẽ đánh giá các lựa chọn thiết kế được thực hiện bởi cả môi trường thực thi tích hợp và mô-đun trong quá trình giải quyết vấn đề hiệu suất cao hơn và mở rộng phạm vi của các ứng dụng có thể hoạt động trên chuỗi.

Thách thức hôm nay

Hiệu suất của một lớp thực thi có thể được đánh giá theo công việc tính toán mà các nút thực thi đạt được so với thời gian khối của chuỗi của họ, hoặc “gas tính được mỗi giây.”

Với điều này trong tâm trí, chúng ta có thể thu hẹp các nút thực thi lớp thành hai yếu tố liên kết: truy cập trạng thái không hiệu quả và tính toán không hiệu quả.

Truy cập trạng thái không hiệu quả đề cập đến chi phí lấy và cập nhật trạng thái blockchain, có thể làm chậm quá trình xử lý giao dịch. Ngược lại, tính toán không hiệu quả là một chức năng của chi phí phát sinh do các thuật toán thực thi các hoạt động và chuyển trạng thái, có thể bao gồm mọi thứ từ việc chuyển giao đơn giản đến hợp đồng thông minh phức tạp và xác minh chữ ký.

Những hạn chế này đang tương hỗ lẫn nhau - sự chậm trễ trong việc truy cập trạng thái có thể làm kéo dài thời gian tính toán, trong khi các thực hành tính toán không hiệu quả có thể gây áp lực cho việc quản lý trạng thái. Hơn nữa, những cải tiến được đề xuất để giải quyết những vấn đề này thường đòi hỏi những cải tiến hệ thống như phân mảnh hoặc áp dụng kiến trúc không có trạng thái, giúp cải thiện việc truy cập và hiệu quả tính toán trạng thái để cải thiện hiệu suất thực thi.

Bottleneck #1: Truy cập trạng thái không hiệu quả

Chi phí và tốc độ cần thiết để truy cập trạng thái của một blockchain là những rào cản quan trọng đối với môi trường thực thi hiệu suất cao và có thể được rút ngắn thành vấn đề về trạng thái phình to.

Trong các chuỗi khối, trạng thái của thế giới được quản lý và cập nhật thông qua cấu trúc dữ liệu cụ thể được gọi là cây. Cây là một phần quan trọng của các chuỗi khối, cung cấp một cách an toàn và hiệu quả để đảm bảo cho các bên bên ngoài nút thực thi có đảm bảo về trạng thái chính xác của chuỗi khối. Mỗi cập nhật trong một trie tạo ra một băm gốc mới, mà các máy khách nhẹ có thể tham khảo để xác minh giao dịch và số dư tài khoản mà không cần duy trì toàn bộ chuỗi.

Ethereum cụ thể dựa vào một cấu trúc dữ liệu được biết đến là cây Merkle Patricia (MPT), gồm có @chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">four sub-tries.

Khi Ethereum thêm nhiều hợp đồng thông minh và token vào trạng thái của mình, cây trạng thái của nó trở nên lớn hơn và phức tạp hơn. Khi trạng thái phát triển, nó đòi hỏi nhiều không gian lưu trữ hơn, nhiều tài nguyên tính toán hơn để xử lý, và nhiều băng thông hơn để truyền. Đồng thời, ràng buộc phần cứng của nút vẫn giữ nguyên mức độ tương tự.

Sự tăng trưởng trạng thái này ảnh hưởng trực tiếp đến hiệu suất của Ethereum vì trạng thái được lưu trữ trên đĩa, và các hoạt động đĩa gây ra chi phí cao. Trong khi truy cập dữ liệu từ một thanh ghi CPU có thể mất 0,1 nanosecond, có thể mất giữa 10 và 100 micro giây(100x–1000x slower)để truy cập dữ liệu từ ổ đĩa, tương đương với khoảng 200.000 hướng dẫn CPU có thể đã được thực thi trong thời gian đó. Điều đó tương đương với một ước lượng thận trọng là 36 giao dịch ERC-20 đã có thể được thực hiện!

Làm trầm trọng thêm vấn đề này, các chuỗi khối có nhiều mẫu truy cập không hiệu quả khi đọc và ghi vào trạng thái. Ví dụ, cấu trúc không tuần tự của cây Merkle Patricia dẫn đến các hoạt động đọc/ghi vào đĩa đầu vào/ra (I/O) từ và đến các vị trí không thể dự đoán trên đĩa. Tính ngẫu nhiên của các đầu vào giao dịch và các thay đổi trạng thái tiếp theo mà chúng kích hoạt dẫn đến mẫu truy cập dữ liệu phân tán gây chậm quá trình xác minh và cập nhật trạng thái và chỉ sử dụng một phần củakhả năng của thiết bị phần cứng.

Tất cả mọi thứ, các nguyên tắc quản lý trạng thái cho các chuỗi khối vẫn còn xa xa so với tiềm năng tuyệt đối của chúng, và có thể thực hiện nhiều tiến bộ để cải thiện hiệu suất tính toán.

Bottleneck #2: Tính toán không hiệu quả

Các lớp thực thi cũng đối mặt với sự chậm trễ của tính toán không hiệu quả, thể hiện qua nhiều cách khác nhau.

Đầu tiên, nhiều quy trình xử lý giao dịch theo thứ tự, không tận dụng đúng cách bộ xử lý đa lõi hiện đại có khả năng xử lý nhiều hoạt động đồng thời. Việc thực thi tuần tự này dẫn đến thời gian chờ CPU không tránh khỏi giữa các giao dịch, lãng phí tài nguyên tính toán quý giá.

Ngoài ra, việc sử dụng máy ảo liên quan đến việc dịch các hoạt động hợp đồng thông minh cấp cao thành bytecode—một mã nguồn thấp hơn, không phụ thuộc vào nền tảng—sau đó được thực thi từng hướng dẫn. Quá trình dịch và thực thi này đem lại chi phí lớn, đặc biệt là đối với các ứng dụng có nhiệm vụ cụ thể của ứng dụng phức tạp và thường xuyên lặp đi lặp lại.

Những hiệu suất kém dẫn đến việc sử dụng tài nguyên máy tính không hiệu quả và làm trở ngại cho hiệu suất của các lớp thực thi.

Giải pháp: Truy cập Trạng thái không hiệu quả

Có một số cách khác nhau mà các nhóm đang cải thiện tỉ lệ mà trạng thái có thể được lấy ra và cập nhật từ phần cứng của nút thực thi, bao gồm việc đơn giản hóa cấu trúc dữ liệu phức tạp và tìm cách giảm thiểu các hoạt động đọc/ghi đĩa tốn kém mà dẫn đến tình trạng phình to trạng thái.

Statelessness & In-Memory Computing

Một số lớp thực thi giải quyết tình trạng tăng kích cỡ trạng thái bằng cách đơn giản chấp nhận nó trong thời gian ngắn. Chúng chuyển lưu trữ dữ liệu trạng thái từ các hệ thống dựa trên đĩa chậm hơn sang bộ nhớ truy cập ngẫu nhiên nhanh hơn (RAM). Việc truy cập thông tin trạng thái trong RAM giảm đáng kể chi phí liên quan đến các hoạt động đĩa, mà chúng chậm hơn và tốn nhiều tài nguyên hơn.

Tuy nhiên, phương pháp này đặt ra thách thức đối với nguyên tắc cốt lõi của phi tập trung. Việc lưu trữ ngày càng lớn dữ liệu trạng thái trong RAM đòi hỏi phải sử dụng phần cứng tiên tiến và đắt tiền hơn, điều này có thể hạn chế khả năng của cá nhân tham gia với vai trò là người vận hành nút. Do đó, khi yêu cầu về phần cứng tăng lên, ít hơn các tổ chức có thể chi trả để vận hành những nút này.

Để cân bằng sự hấp dẫn của tính toán trong bộ nhớ với việc tối thiểu hóa sự tin cậy, cả L1s (như Ethereum) và L2s đều đang theo đuổi một lộ trình mở rộng dựa trên việc chia tách vai trò của một người xác minh thành các nút thực thi tập trung riêng biệt với nhiều nút xác minh. Trong mô hình này, các nhà sản xuất khối hiệu suất cao với yêu cầu phần cứng để tính toán trong bộ nhớ chịu trách nhiệm tạo ra các khối, và các chứng minh mật mã (chứng minh gian lận và chứng minh tính hợp lệ) được tận dụng bởi các nút xác minh để giữ cho các nhà sản xuất khối chịu trách nhiệm.

Kết quả, những hệ thống này nên cho phép các nhà sản xuất khối tối đa hóa tốc độ của họ vì họ có thể tính toán trong bộ nhớ, loại bỏ hoàn toàn các I/O đĩa trong quá trình thực thi. Vì độ trễ của RAM thường dưới 100 nanosecond, độ trễ của việc truy cập trạng thái giảm đi đến 1000 lần so với các triển khai dựa trên đĩa.

Song song với đó, các bằng chứng gian lận và tính hợp lệ được sử dụng thay vì sự đồng thuận phân quyền để mở rộng các thuộc tính hạn chế tin cậy của hệ thống cùng với công suất xử lý của nó. Kết quả là, các nút sản xuất khối tập trung mạnh mẽ được cân bằng bởi các nút xác minh có thể chạy trên phần cứng ít tốn kém hơn nhiều. Các nút này thực hiện chức năng quan trọng của việc độc lập xác minh các bằng chứng chuyển trạng thái (hoặc chuyển trạng thái không hợp lệ) để duy trì một cái nhìn chính xác về trạng thái mà không gánh nặng lưu trữ toàn bộ trạng thái chuỗi khối.

Để hỗ trợ quá trình này một cách tối thiểu hóa niềm tin, các lớp thực thi phải triển khai một mức độ của vô quốc tịch, điều phổ biến nhất là khái niệm về “trạng thái không mạnh.” Trạng thái không mạnh được đạt được bằng cách yêu cầu các nhà sản xuất khối cung cấp một chứng nhận mật mã được biết đến như là một chứng kiếnđến một nút xác minh. Nhân chứng này bao gồm tất cả các thay đổi trạng thái đề xuất bởi khối mới, cho phép các máy xác minh xác minh những thay đổi này mà không cần dữ liệu lịch sử bổ sung.

Mặc dù khái niệm này có thể được áp dụng bằng cách sử dụng các cấu trúc cây khác nhau, cây Verkle thường được ưa chuộng hơn Merkle vì hiệu quả của chúng. Cây Merkle yêu cầu bao gồm tất cả các băm của các nút anh em dọc theo đường dẫn từ một điểm dữ liệu (lá) đến gốc của cây để chứng minh tính toàn vẹn dữ liệu. Yêu cầu này có nghĩa là kích thước của bằng chứng (bằng chứng tính toàn vẹn) tăng theo chiều cao của cây, vì mỗi cấp độ đều đòi hỏi thêm các băm. Do đó, việc xác minh tính toàn vẹn dữ liệu trong cây Merkle trở nên tốn công và tốn kém tính toán, đặc biệt là đối với các bộ dữ liệu lớn. Ngược lại, cây Verkle tối ưu hóa quy trình này, giảm bớt chi phí tính toán và lưu trữ liên quan đến việc tạo ra và xác minh các khối mới.

Verkle tree scaling từ “Verkle Tree” của Ethereum không thể tránh khỏi

Cây Verkle tăng cường cấu trúc của cây Merkle传统 bằng cách tối ưu hóa các kết nối giữa các lá và gốc và loại bỏ nhu cầu bao gồm các nút anh em trong quá trình xác minh. Trong cây Verkle, việc xác minh một chứng minh chỉ liên quan đến giá trị tại nút lá, cam kết với nút gốc và cam kết vector duy nhất dựa trên cam kết đa thức, thay thế các cam kết dựa trên băm đa phần tìm thấy trong cây Merkle. Sự chuyển đổi này cho phép cây Verkle duy trì một chứng chỉ kích thước cố định, không tăng lên theo chiều cao của cây hoặc số lá được xác minh, cải thiện đáng kể hiệu quả của lưu trữ và tính toán trong quá trình xác minh dữ liệu.

Trong những năm sắp tới, chúng ta sẽ thấy việc triển khai tình trạng không có trạng thái xảy ra ở cấp độ L1 và L2 với các cấu hình khác nhau. Theo lộ trình Ethereum mới nhất, các người xác minh có thể dựa vào người xây dựng khối để cung cấp chứng minh Verkle về trạng thái của một số khối và xác minh các chứng minh nhẹ này thay vì duy trì trạng thái của Ethereum trực tiếp.

Ở cấp độ L2, các đội như MegaETHđang tích cực áp dụng khái niệm vô trạng thái vào thiết kế của optimistic rollups. Trong thiết kế của họ, nút sequencer tạo ra một bằng chứng cho mỗi khối chứa các giá trị trạng thái cần thiết và các băm trung gian trong khi phát ra một state delta đại diện cho các thay đổi trong trạng thái. Các nút xác minh sau đó có thể thực thi lại bất kỳ khối nào bằng cách lấy bằng chứng từ lớp DA hoặc mạng ngang hàng mà không cần lưu trữ toàn bộ trạng thái. Đồng thời, các nút đầy đủ cập nhật trạng thái của họ bằng cách áp dụng các state delta được phân phối qua mạng, cho phép họ duy trì đồng bộ mà không cần thực thi lại các giao dịch hoặc lưu trữ toàn bộ lịch sử trạng thái.

Tuy nhiên, cũng đáng lưu ý rằng các lợi ích của việc không có trạng thái và khả năng tính toán trong bộ nhớ không phải là một viên đạn bạc cho hiệu suất của lớp thực thi.

Chỉ số TPS thời gian thực từ bài viết “Hiểu về Hiệu suất Lớp Thực thi Ethereum của MegaETH”

Là một trong những người sáng lập của MegaETH, Yilong Li đã xác định trong phần tiếp theo bảng trình bày nghiên cứuvề việc thực thi trên Ethereum, có những không hiệu quả khác đối với cấu trúc dữ liệu và mẫu truy cập trên chuỗi vẫn được tối ưu hóa.

Cải thiện cơ sở dữ liệu

Các nhóm làm việc trên các lớp thực thi đang tìm cách cải thiện cấu trúc của các cơ sở dữ liệu này để loại bỏ một số hạn chế mà Ethereum và các chuỗi khối tương thích EVM khác gặp phải khi xử lý truy cập trạng thái không hiệu quả, điều này ảnh hưởng đến hiệu suất tính toán.

Trên thực tế, các hạn chế của các thiết kế cơ sở dữ liệu hiện có được tìm thấy trong EVM đã được thông báoCủa Monad* quyết định vượt ra khỏi việc tối ưu hóa chỉ về hiệu suất tính toán để đạt được sự song song hóa. Monad đã nhận thấy rằng ngay cả sau khi triển khai thực thi song song, họ chỉ thấy một ít cải thiện về hiệu suất vì các yêu cầu đọc và ghi đa luồng tới cơ sở dữ liệu đã chặn lẫn nhau. Do đó, Monad triển khai một cơ sở dữ liệu tương thích với IO không đồng bộ (AIO), hoặc truy cập song song, là một phần quan trọng của giải pháp.

Async I/O

Các hoạt động I/O — như đọc từ hoặc ghi vào thiết bị lưu trữ — thường tạo ra các chướng ngại vật, đặc biệt là với ổ cứng cơ học (HDD). Những ổ cứng này đòi hỏi sự di chuyển vật lý của đầu đọc/ghi để truy cập dữ liệu, điều này có thể làm chậm quá trình xử lý dữ liệu đáng kể.

AIO giải quyết thách thức này bằng cách cho phép các chương trình thực hiện các hoạt động I/O song song với các quy trình khác. Theo cách này, một chương trình có thể khởi tạo một hoạt động I/O và tiếp tục mà không cần chờ đợi cho đến khi hoàn thành. Điều này được thực hiện bằng cách đăng ký một hàm gọi lại hoặc một promise mà hệ điều hành hoặc một thư viện I/O sẽ thực hiện sau khi hoạt động I/O hoàn thành. Cách tiếp cận không đồng bộ này cho phép chương trình chính tiếp tục thực thi các nhiệm vụ khác, cải thiện hiệu suất tổng thể bằng cách không chờ đợi cho các nhiệm vụ I/O hoàn thành.

Asynchronous I/O có thể được triển khai với cả ổ đĩa cứng truyền thống và ổ đĩa state-state (SSDs), mặc dù những lợi ích rõ ràng hơn khi sử dụng SSDs. HDDs có thể thực hiện AIO, nhưng tính cơ khí của chúng có nghĩa là chúng chậm hơn so với SSDs, chúng lưu trữ dữ liệu trên bộ nhớ flash và không có bộ phận di chuyển, dẫn đến thời gian truy cập nhanh hơn.

Ví dụ, Monad sử dụng một state backend tùy chỉnh được tối ưu hóa cho lưu trữ SSD, hỗ trợ mức độ xử lý dữ liệu song song cao và giảm thiểu độ trễ I/O. Thiết lập này hiệu quả hơn so với các hệ thống chỉ dựa vào lưu trữ trên đĩa truyền thống hoặc các hệ thống sử dụng cơ sở dữ liệu trong bộ nhớ, có thể vẫn phải đối mặt với sự trễ từ việc ghi dữ liệu thường xuyên vào và đọc từ phương tiện lưu trữ chậm hơn.

Tương tự, Reth sử dụng một phương pháp tách biệt các hoạt động cơ sở dữ liệu khỏi bộ máy thực thi EVM. Thiết lập này cho phép bytecode EVM thực thi tuần tự trên một luồng duy nhất để duy trì tính nhất quán trong khi các nhiệm vụ I/O cơ sở dữ liệu được chuyển sang các quá trình song song. Reth sử dụng mô hình diễn viên - một mẫu kiến trúc phần mềm - để quản lý các quá trình song song này một cách hiệu quả, đảm bảo rằng các hoạt động I/O không làm gián đoạn trình thông dịch EVM.

Tần suất Merklization trạng thái

Một vector khác cho việc tối ưu hóa là tần suất merklization của trạng thái. Mô hình hiện tại của Ethereum về việc merklizing trạng thái sau mỗi khối đưa ra chi phí lớn, đòi hỏi việc ghi thường xuyên vào và đọc từ ổ đĩa và duyệt trie liên tục. Cây Merkle thường hoạt động bằng cách nhóm các băm trung gian thành các nhóm 16 (gọi là một nút) và lưu trữ chúng trong cơ sở dữ liệu key-value store nơi key là băm nút và giá trị là nút đó.

Việc duyệt cây này để tìm và cập nhật dữ liệu đòi hỏi một lần truy cập đĩa ngẫu nhiên cho mỗi lớp của cây cần được duyệt, và việc duyệt một cây Merkle ngây thơ sẽ đòi hỏi khoảng tám truy vấn cơ sở dữ liệu tuần tự mỗi mục.

Phương pháp của Solana cập nhật cam kết trạng thái chỉ vào cuối mỗi kỷ nguyên cho phép phân tán chi phí ghi đè qua nhiều giao dịch trong giai đoạn đó. Nếu một bản ghi trạng thái được sửa đổi nhiều lần trong cùng một kỷ nguyên, mỗi lần ghi không đòi hỏi cập nhật ngay lập tức đến gốc Merkle. Điều này giảm thiểu tổng chi phí tính toán liên quan đến việc cập nhật trạng thái trong kỷ nguyên. Do đó, chi phí liên quan đến việc đọc từ trạng thái duy trì không đổi, hoặc O(1), vì trạng thái có thể được đọc trực tiếp mà không cần phải đi qua một đường đường dẫn Merkle mỗi lần.

Việc giảm tần suất merklization trong Ethereum có thể giảm thiểu chi phí đọc và ghi trạng thái, nâng cao hiệu suất. Tuy nhiên, các máy khách nhẹ sẽ cần phải chơi lại các thay đổi khối để theo dõi trạng thái giữa các kỷ nguyên hoặc gửi giao dịch onchain để xác minh trạng thái, và thay đổi như vậy hiện không tương thích với Ethereum.

Cấu trúc Dữ liệu Hiệu quả & Chuyên biệt

Ngoài ra, cấu trúc cây lớp trong các máy khách Ethereum hiện có thường gây ra các mô hình truy cập trạng thái không hiệu quả, góp phần làm tăng trạng thái. Trong khi trạng thái của Ethereum được cấu trúc dưới dạng MPT, nó cũng được lưu trữ trong cơ sở dữ liệu máy khách Ethereum như LevelDB,PebbleDB(được sử dụng bởi go-ethereum), hoặc MDBX (được sử dụng bởi Erigon) lưu trữ dữ liệu trong cây Merkle như một B-Tree hoặc LSM-Tree.

Trong cài đặt này, một cấu trúc dữ liệu được gốc vào một cấu trúc dữ liệu khác của một loại riêng biệt, tạo ra “tăng cường đọc” từ việc điều hướng cấu trúc cây nội bộ trên các máy khách hoạt động dưới một hệ thống dựa trên cây Merkle khác. Tăng cường đọc có thể được hiểu là kết quả của nhiều bước để truy cập hoặc cập nhật thông tin chứa trong một trạng thái, điều này đòi hỏi điều hướng cây bên ngoài để tìm điểm nhập vào MPT trước khi thực hiện hoạt động cần thiết. Do đó, số lần truy cập đĩa cho một đọc ngẫu nhiên được nhân với một yếu tố log(n).

Để giải quyết vấn đề này, Monad tự nhiên sử dụng cấu trúc dữ liệu Patricia trie trên đĩa và trong bộ nhớ. Từ góc độ kỹ thuật, Patricia tries thường áp đảo các cấu trúc cây Merkle khác nhờ sự kết hợp độc đáo của hiệu suất không gian, khớp tiền tố hiệu quả và duyệt node tối thiểu. Thiết kế của trie gộp các node có con đơn và tối ưu hóa tìm kiếm, chèn và xóa, giảm số lần thực hiện thao tác I/O đĩa hoặc mạng cần thiết. Hơn nữa, khả năng của Patricia trie trong xử lý khớp tiền tố tăng cường hiệu suất trong các ứng dụng cần tìm kiếm khóa một phần nhanh chóng.

Một hạn chế khác cụ thể đối với cấu trúc dựa trên cây là việc truy cập hoặc cập nhật dữ liệu đòi hỏi phải duyệt qua nhiều lớp, dẫn đến nhiều truy cập đĩa tuần tự.Sovereign Labsđịa chỉ này bằng cách ủng hộ cấu hình cây Merkle nhị phân. Sự chuyển đổi quan trọng này sang một cấu trúc nhị phân giảm đáng kể số lượng đường dẫn tiềm năng trong quá trình duyệt cây, giảm thiểu trực tiếp số lượng tính toán băm cần thiết cho các cập nhật, chèn và chứng minh mật mã.

Cấu hình cây Merkle nhị phân từ bài báo “Nearly Optimal State Merklization” của Sovereign Labs

Một ví dụ bổ sung trong danh mục này là nhóm Reth cấu hình Reth để tải trước các nút trie trung gian từ đĩa trong quá trình thực thibằng cách thông báo dịch vụ gốc trạng thái về các khe lưu trữ và tài khoản bị ảnh hưởng.

Hết hạn trạng thái

Hết hạn trạng thái là một cơ chế để quản lý và giảm kích thước của trạng thái blockchain bằng cách loại bỏ dữ liệu mà không được truy cập trong một khoảng thời gian nhất định. Mặc dù hết hạn thường được phân loại trong danh mục “vô trạng thái”, nhưng quan trọng là phải phân biệt những khái niệm này trong ngữ cảnh của thực thi.

Tình trạng không có trạng thái cải thiện việc thực hiện bằng cách tăng khả năng tính toán trong bộ nhớ của một nút thực hiện, nhưng sự cải thiện trong việc thực hiện đến từ yêu cầu phần cứng mạnh mẽ hơn trên ít nút thực hiện giao dịch. Ngược lại, việc hết hạn trạng thái có thể được áp dụng cho các blockchain với cả ít và nhiều nút thực hiện.

Có một vài phương pháp thường được thảo luận để thực hiện việc hết hạn trạng thái:

• Hết hạn theo thuê: Phương pháp này liên quan đến việc tính phí bảo trì hoặc “thuê” để giữ cho tài khoản hoạt động trong cơ sở dữ liệu của trạng thái. Nếu không trả tiền thuê, các tài khoản sẽ được lưu trữ dưới dạng hồ sơ cho đến khi một khoản phí được trả để khôi phục chúng.
• Hết hạn theo thời gian: Ở đây, các tài khoản được coi là không hoạt động nếu chúng không được truy cập—nghĩa là không có giao dịch hoặc tương tác—trong một khoảng thời gian cụ thể.

Cả hai phương pháp đều nhằm mục đích duy trì chỉ dữ liệu được sử dụng một cách tích cực trong trạng thái có thể truy cập ngay lập tức trong khi đẩy dữ liệu cũ hơn, ít được truy cập thường xuyên hơn đến trạng thái lưu trữ không gây gánh nặng cho hệ thống chính.

Bằng cách duy trì trạng thái nhỏ hơn và dễ quản lý hơn, hết hạn trạng thái làm giảm "trạng thái phình to" có thể cản trở nghiêm trọng hiệu suất blockchain. Kích thước trạng thái nhỏ hơn cho phép các nút nhanh chóng điều hướng và cập nhật trạng thái, chuyển thành thực thi nhanh hơn vì các nút dành ít thời gian quét hơn và nhiều thời gian xử lý hơn.

Thực thi Sharding

Sharding tối ưu hóa việc sử dụng tài nguyên và hiệu suất bằng cách phân phối nhiệm vụ và dữ liệu trên một số lượng giới hạn các nút chuyên biệt (không phải mọi nút thực thi một trạng thái toàn cầu).

Trong kiến trúc blockchain phân mảnh, trạng thái toàn cầu được chia thành các phân vùng riêng biệt được gọi là mảnh. Mỗi mảnh duy trì một phần của trạng thái và chịu trách nhiệm xử lý một phần của giao dịch mạng. Các giao dịch được gán cho các mảnh cụ thể dựa trên một hàm phân tầng xác định trước, xem xét các yếu tố khác nhau như địa chỉ người gửi, địa chỉ người nhận và băm dữ liệu giao dịch. Điều này giảm thiểu nhu cầu giao tiếp giữa các mảnh và cho phép thực thi giao dịch hiệu quả hơn.

Sơ đồ chia nhỏ từ bài viết của Vitalik về “Giới Hạn của Khả năng Mở Rộng Của Blockchain”

Điều này trở nên rõ ràng khi khám phá NEAR Protocol’s thiết kế sharding, Nightshade, giúp đạt được trạng thái không có trạng thái để tăng cường sharding mà không ảnh hưởng đến việc tối thiểu hóa sự tin cậy.

Trong Nightshade, blockchain được cấu trúc như một chuỗi logic duy nhất, với mỗi khối được tạo thành từ nhiều “khối” và một khối được phân bổ cho mỗi shard. Những khối này chứa các giao dịch và chuyển đổi trạng thái cụ thể cho mỗi shard. Bao gồm các khối từ tất cả shards trong một khối duy nhất cho phép có một cái nhìn thống nhất về trạng thái toàn bộ blockchain và đơn giản hóa quá trình giao tiếp giữa các shard.

Tương tự như sự phân tách giữa proper-builder (PBS) trên Ethereum, Nightshade rõ ràng phân biệt vai trò của các nút có trạng thái và không có trạng thái. Trên NEAR, các nhà xác minh có trạng thái được gán cho các shard cụ thể và chịu trách nhiệm thu thập giao dịch, thực thi chúng và tạo ra các khối cụ thể của shard. Họ duy trì toàn bộ trạng thái của shard được giao và tạo ra các chứng nhân trạng thái để các nhà xác minh sử dụng trong quá trình xác minh.

Trong khi đó, những người xác nhận không trạng thái được chỉ định ngẫu nhiên để xác nhận các shard cụ thể trên cơ sở từng khối. Họ không cần duy trì trạng thái shard đầy đủ và phụ thuộc vào nhân chứng trạng thái do nhà sản xuất khối từ các shard khác cung cấp để xác nhận các chuyển đổi trạng thái và giao dịch trong một đoạn. Việc chỉ định ngẫu nhiên người xác nhận cho các shard giúp đảm bảo an ninh và tính toàn vẹn của mạng, vì nó làm cho việc hợp tác và kiểm soát shard cụ thể của các tác nhân độc hại trở nên khó khăn hơn.

Vì mỗi nút trong mạng chỉ cần xử lý dữ liệu cho phần shard tương ứng của mình chứ không phải dữ liệu của toàn bộ mạng, nên gánh nặng lưu trữ và tính toán trên các nút cá nhân được giảm bớt.

Giải pháp: Tính toán không hiệu quả

Thực thi song song

Lúc để giải quyết vấn đề lớn: song song hóa. Việc song song hóa thực hiện giao dịch cho phép xử lý nhiều giao dịch bằng cách sử dụng nhiều tài nguyên máy tính đồng thời. Điều này cho phép tăng công suất khi tài nguyên phần cứng được mở rộng trong những giai đoạn có nhu cầu cao.

Tuy nhiên, quan trọng là cần xem xét rằng nhiều thành phần thực thi có thể được song song hóa, trong đó nhiều thành phần được triển khai bởi các bộ xử lý phụ như Lagrange* và các khách hàng blockchain thay thế như Firedancerđể cải thiện hiệu suất của các chuỗi khối đột phá đáng kể. Cụ thể, song song hóa có thể bao gồm:

• Tăng tốc Truy cập Trạng thái
• Phân luồng các hoạt động cụ thể
• Song song hóa quyết định và thực thi

Tăng tốc Truy cập Trạng thái

Tăng tốc truy cập trạng thái song songmang lại hai lợi ích quan trọng:

• Parallel EVMs phân phối xử lý giao dịch trên nhiều lõi CPU. Thiết lập này cho phép nhiều giao dịch được xử lý đồng thời thay vì buộc chúng phải xếp hàng chờ đợi cho một tài nguyên duy nhất.
• Khi giao dịch chờ dữ liệu từ bộ nhớ lưu trữ - điều này có thể tạo ra độ trễ đáng kể - hệ thống không ở trạng thái rảnh. Thay vào đó, nó có thể chuyển sang một giao dịch khác đã sẵn sàng để thực thi. Điều này là có thể bởi vì nhiều lõi có thể xử lý các nhiệm vụ khác nhau độc lập và đồng thời.

Thách thức chính trong việc song song hóa việc thực thi giao dịch đến từ việc quản lý truy cập song song vào trạng thái toàn cầu chung mà không vi phạm ACIDquy tắc cập nhật hệ thống phân tán. Nếu một chuỗi khối có một lô giao dịch đang thực thi song song, một số trong số chúng sẽ xung đột. Do đó, hai phương pháp chính để song song hóa truy cập trạng thái khác nhau khi chúng dành tài nguyên để giải quyết xung đột: mô hình thực thi bi quan (hoặc khóa bộ nhớ) và mô hình thực thi lạc quan.

Thực thi bi quan

Mô hình thực thi bi quan là một phương pháp xử lý giao dịch yêu cầu giao dịch khai báo các biến trạng thái mà họ sẽ truy cập (đọc hoặc ghi) trong quá trình thực thi. Thông tin này được bao gồm trong siêu dữ liệu của giao dịch, cho phép thời gian chạy phân tích các mẫu truy cập trước khi thực thi.

Bằng cách xem xét các mẫu truy cập đọc-viết, thời gian chạy có thể xác định các giao dịch với các tập truy cập không chồng lấp, cho phép thực hiện song song các giao dịch không chồng lấp và chỉ đọc và cải thiện công suất. Thời gian chạy tạo hàng đợi giao dịch song song cho mỗi luồng CPU trên một nút xác thực, đảm bảo rằng các giao dịch với các mẫu truy cập không xung đột được xử lý đồng thời.

Kết quả của lựa chọn thiết kế này, mô hình thực thi bi quan được lợi ích từ việc kiểm soát tinh tế trên việc phân bổ tài nguyên, cho phép phân đoạn hoặc phân chia không gian trạng thái của một chuỗi khối.

Parallelization tạo ra hiệu quả nhiều phân đoạn thực thi độc lập có thể kết hợp đồng bộ được củng cố bởi một mô hình bảo mật thống nhất. Nó giúp giải quyết tắc nghẽn mạng và tối ưu hóa chi phí khí đốt thông qua quản lý tài nguyên chính xác và thị trường phí năng động. Bằng cách xác định các "điểm nóng" truy cập của nhà nước (các khu vực có nhu cầu giao dịch cao), hệ thống có thể thực hiện các tối ưu hóa được nhắm mục tiêu như định giá phí khác biệt, giới hạn tỷ lệ hoặc phân bổ các nguồn lực bổ sung cho các quốc gia tranh chấp cao. Điều quan trọng cần lưu ý là việc triển khai song song hóa hiện tại của Solana không đầy đủ nhận ra tiềm năng của các thị trường phí cục bộ.

Để đảm bảo tính nhất quán dữ liệu trong truy cập đồng thời, mô hình thực thi bi quan sử dụng cơ chế khóa. Trước khi một giao dịch có thể truy cập vào một biến trạng thái cụ thể, nó phải có được khóa trên biến đó. Khóa cung cấp cho giao dịch quyền truy cập độc quyền vào biến, ngăn ngừa các giao dịch khác thay đổi nó đồng thời. Khóa được giải phóng sau khi giao dịch được thực thi, cho phép các giao dịch khác truy cập vào biến.

Trong Solana’s Mực nước biểnthời gian chạy, mà triển khai mô hình thực thi bi quan này, các giao dịch xác định các tài khoản mà chúng sẽ đọc hoặc ghi trong quá trình thực thi. Sealevel phân tích các mẫu truy cập và xây dựng hàng đợi giao dịch song song cho mỗi luồng CPU trên một nút xác nhận. Nếu một tài khoản được truy cập nhiều lần, nó sẽ được liệt kê một cách tuần tự trong một hàng đợi duy nhất để ngăn chặn xung đột. Các giao dịch không được xử lý trong thời gian khối của nút lãnh đạo sẽ được gói gọn và chuyển tiếp đến nút lãnh đạo tiếp theo được lên lịch để xử lý.

Các hệ thống dựa trên Unspent transaction output (UTXO) cải thiện hiệu suất tính toán tương tự. UTXOs liên quan đến các đơn vị tiền tệ cụ thể - UTXOs - liên kết với ví của một cá nhân. Đối với mỗi giao dịch của ví đó, UTXOs được tiêu tốn và thay thế bằng những cái mới; một hoặc nhiều UTXOs được tạo ra cho người nhận, đại diện cho khoản thanh toán, và một cái khác thường được tạo ra cho người khởi xướng, đại diện cho bất kỳ thay đổi trả lại nào.

Bằng cách xác định các hợp đồng sẽ được chạm vào, các giao dịch chạm vào các tập hợp hợp đồng không giao nhau có thể được thực hiện song song bằng cách thực thi các nút (có thể được thực hiện trong mô hình dữ liệu “tài khoản” với các danh sách truy cập nghiêm ngặt). Tuy nhiên, để đạt tính tương thích với các hợp đồng thông minh theo kiểu Ethereum, các kế hoạch UTXO như giới hạn của Fuel đối với các nút tạo khối để thực thi các giao dịch với các danh sách truy cập chồng chéo theo thứ tự.

Tuy nhiên, mô hình thực thi bi quan có những hạn chế. Các giao dịch phải khai báo mẫu truy cập của họ một cách chính xác từ đầu, điều này có thể là thách thức đối với các giao dịch phức tạp hoặc động nơi mẫu truy cập có thể phụ thuộc vào dữ liệu đầu vào hoặc logic có điều kiện. Việc khai báo mẫu truy cập không chính xác hoặc không đầy đủ có thể gây ra hiệu suất không tối ưu và lỗi thời gian chạy tiềm năng. Ngoài ra, cơ chế khóa có thể tạo ra độ trễ và giảm sự cạnh tranh khi nhiều giao dịch cạnh tranh cho các biến trạng thái giống nhau. Sự cạnh tranh này có thể tạo thành chướng ngại về hiệu suất, vì các giao dịch có thể dành một phần đáng kể thời gian thực thi của họ đang chờ để có được khóa trên các biến trạng thái đòi hỏi cao.

Quan trọng hơn, mô hình này đặt gánh nặng lớn cho các nhà phát triển, họ phải hiểu rõ về sự phụ thuộc dữ liệu của hợp đồng để chỉ định truy cập trạng thái cần thiết một cách chính xác trước. Sự phức tạp này có thể tạo ra thách thức, đặc biệt là trong việc thiết kế ứng dụng với tương tác trạng thái động và phức tạp, như sàn giao dịch phi tập trung hoặc nhà làm thị trường tự động.

Thực hiện lạc quan

Trái lại, mô hình thực thi lạc quan áp dụng một cách tiếp cận “đoán định” đối với việc thực thi giao dịch, cho phép giao dịch thực thi song song mà không cần phải khai báo trạng thái ban đầu trước.

Thay vì ngăn chặn xung đột trước khi xảy ra, các giao dịch được thực hiện một cách lạc quan song song, giả định rằng chúng độc lập. Thời gian chạy sử dụng các kỹ thuật như kiểm soát đồng thời nhiều phiên bản(MVCC) vàbộ nhớ giao dịch phần mềm(STM) để theo dõi các bộ đọc và ghi trong quá trình thực thi. Sau khi thực thi, thời gian chạy phát hiện xung đột hoặc phụ thuộc. Nó thực hiện các biện pháp sửa đổi, chẳng hạn như hủy và thực thi lại các giao dịch xung đột, nhưng có thể làm điều đó bằng cách đọc từ bộ nhớ thay vì đĩa để xác định các giao dịch xung đột.

Mô hình thực thi lạc quan đơn giản hóa quá trình phát triển, cho phép các lập trình viên tập trung vào việc viết logic hợp đồng mà không cần lo lắng về việc khai báo mẫu truy cập trạng thái. Do giao dịch không cần phải khai báo tương tác với trạng thái của họ ngay từ đầu, các nhà phát triển được cấp quyền tự do hơn trong việc thiết kế hợp đồng thông minh của họ, cho phép tương tác phức tạp và động với trạng thái blockchain. Mô hình thực thi lạc quan đặc biệt phù hợp cho các nền tảng hỗ trợ số lượng giao dịch lớn và các ứng dụng phức tạp, vì nó có thể cung cấp công suất xử lý cao hơn và khả năng mở rộng hơn so với mô hình bi quan.

Một triển khai đáng chú ý của mô hình này được tìm thấy trong Aptosvà MoveVM củaMovement Labs*, sử dụng một kỹ thuật được biết đến là Block-STM. Trong Block-STM, các giao dịch được thực hiện song song trước; sau đó, các giao dịch xung đột được xác định và lên lịch để thực hiện lại dựa trên các phụ thuộc được phát hiện. Phương pháp này đảm bảo tài nguyên xử lý được sử dụng liên tục, cải thiện sản lượng trong khi duy trì tính toàn vẹn của luồng công việc giao dịch.

Khối Block-STM của Aptos từ “Mở rộng Thực thi Blockchain bằng cách Biến Lời Nguyền Thứ Tự thành Ân Huệ Hiệu Năng”

Mặc dù có nhiều ưu điểm, mô hình thực thi lạc quan cũng đồng thời mang lại những thách thức. Nhu cầu phát hiện xung đột thời gian chạy và khả năng hủy giao dịch và thử lại đều tạo ra chi phí tính toán và phức tạp. Ngoài ra, việc duy trì nhiều phiên bản của trạng thái và quản lý chi phí liên quan đến giải quyết xung đột yêu cầu thiết kế hệ thống tinh vi và cơ chế kiểm soát đồng thời mạnh mẽ để đảm bảo tính toàn vẹn và hiệu suất của blockchain.

Block-STM tận dụng MVCC để quản lý hiệu quả các ghi đồng thời và duy trì nhiều phiên bản dữ liệu, từ đó ngăn chặn xung đột giữa các hoạt động ghi đồng thời. Nó tích hợp một bộ lập lịch cộng tác để phối hợp các nhiệm vụ thực thi và xác nhận trên nhiều luồng, đảm bảo các giao dịch được thực hiện theo thứ tự chúng được bắt đầu. Thiết lập này giảm thiểu việc hủy giao dịch bằng cách sử dụng ước lượng phụ thuộc động, cho phép các giao dịch với phụ thuộc chờ đợi và giải quyết phụ thuộc này một cách hiệu quả trước khi tiếp tục.

Ngoài ra, mô hình tài khoản được sử dụng bởi MoveVM khác biệt so với EVM của Ethereum, dẫn đến ít xung đột hơn. Trong Ethereum, một token thường được quản lý bởi một hợp đồng thông minh duy nhất, có thể gây ra nhiều giao dịch token tương tác thông qua cùng một địa chỉ hợp đồng, tăng khả năng xảy ra xung đột. Ngược lại, MoveVM gán các token cho các tài khoản người dùng cá nhân, giảm cơ hội xảy ra xung đột do mỗi giao dịch thường tương tác với các địa chỉ tài khoản khác nhau.

Trong Monad, tập hợp ban đầu các giao dịch được thực hiện song song có thể được xây dựng dưới dạng một giai đoạn I/O, có thể tạo ra kết quả có thể cam kết ngay lập tức, và giai đoạn “thử lại” tiếp theo, đòi hỏi một lượng công việc nhỏ để xử lý các giao dịch còn xung đột. Những chuyển đổi xung đột này được hiển thị và đưa vào bộ nhớ cache, cho phép giảm thiểu overhead thực thi vì chúng sống trong bộ nhớ. Trong khi hầu hết trạng thái sống trên đĩa, các giao dịch xung đột được truy cập nhanh chóng vào thời gian thực thi.

Mô hình thực hiện bi quan và lạc quan cung cấp các phương pháp khác nhau để xử lý thực hiện giao dịch và quản lý trạng thái trong các chuỗi khối. Sự lựa chọn giữa những mô hình này liên quan đến sự đánh đổi giữa sự phức tạp ban đầu trong việc chỉ định truy cập trạng thái và sự tăng cường tính toán liên quan đến việc giải quyết xung đột động.

Song song dữ liệu & nhiệm vụ

Song song dữ liệu và nhiệm vụ tập trung vào việc tối ưu hóa hiệu suất bằng cách phân phối tải tính toán trên nhiều bộ xử lý: song song dữ liệu phân đoạn tập dữ liệu để xử lý đồng thời, trong khi song song nhiệm vụ gán các nhiệm vụ khác nhau cho các bộ xử lý khác nhau để hoạt động đồng thời.

Những tối ưu hóa này là khác biệt nhưng có liên kết với sự song song truy cập trạng thái, quản lý và đồng bộ hóa truy cập vào tài nguyên chia sẻ như bộ nhớ hoặc cơ sở dữ liệu để ngăn xung đột và đảm bảo tính toàn vẹn dữ liệu khi nhiều quy trình hoặc luồng hoạt động đồng thời.

Data Parallelism

Data parallelism involves parallelizing specific operations across multiple data elements simultaneously. This approach is particularly beneficial when the same operation needs to be applied to a large dataset or when performing computationally intensive operations on multiple input values. The key unlock comes from distributing the data across multiple processing units and executing the same operation concurrently on different data elements.

Một kỹ thuật phổ biến cho song song dữ liệu là một chỉ thị, nhiều dữ liệu (SIMD), cho phép một chỉ thị duy nhất được thực hiện đồng thời trên nhiều phần tử dữ liệu. CPU hiện đại thường có khả năng SIMD tích hợp, cho phép chúng thực hiện các hoạt động song song trên nhiều điểm dữ liệu. Bằng cách tận dụng các chỉ thị SIMD, các nhà phát triển có thể đạt được sự tăng tốc đáng kể đối với một số loại hoạt động, như tính toán toán học, biến đổi dữ liệu, hoặc xử lý tín hiệu.

Ví dụ, hãy xem xét một tình huống trong đó bạn phải áp dụng một hàm toán học phức tạp cho một mảng số lớn. Thay vì xử lý từng số theo thứ tự, SIMD có thể hoạt động trên nhiều số cùng một lúc. Việc xử lý đồng thời này được thực hiện bằng cách tải một phần của các số vào thanh ghi SIMD của CPU, thực hiện hàm toán học trên tất cả các số được tải theo cách song song, sau đó lưu kết quả trở lại bộ nhớ. Bằng cách xử lý nhiều số cùng một lúc, SIMD có thể giảm thiểu đáng kể thời gian thực thi tổng thể.

Công việc của Firedancer trên ED25519 Xác minh chữ ký thể hiện sức mạnh của SIMD để tối ưu hóa các tính toán phức tạp. Quá trình xác minh chữ ký liên quan đến các phép toán số học trong Galois Fields, có thể chuyên sâu về mặt tính toán. Bằng cách tận dụng các hướng dẫn SIMD, Firedancer có thể thực hiện các thao tác này trên nhiều yếu tố dữ liệu đồng thời, dẫn đến cải thiện hiệu suất đáng kể. Những tối ưu hóa này sẽ rất quan trọng trong việc cải thiện hiệu suất của Solana, vốn đã thực hiện song song quyền truy cập của nhà nước.

Task Parallelism

Parallelism nhiệm vụ liên quan đến việc song song hóa các nhiệm vụ hoặc hoạt động khác nhau trong một chương trình trên nhiều đơn vị xử lý. Phương pháp này hữu ích khi một chương trình bao gồm nhiều nhiệm vụ độc lập có thể được thực hiện đồng thời. Bằng cách gán mỗi nhiệm vụ cho một đơn vị xử lý riêng biệt, chẳng hạn như một lõi CPU hoặc một GPU, thời gian thực thi tổng thể có thể được giảm.

Song song nhiệm vụ thường được sử dụng trong các tình huống mà một chương trình cần thực hiện nhiều hoạt động phức tạp đồng thời. Ví dụ, hãy xem xét một ứng dụng xử lý video cần áp dụng các bộ lọc và hiệu ứng khác nhau vào luồng video theo thời gian thực. Thay vì sử dụng mỗi đơn vị tính toán để cùng nhau áp dụng từng bộ lọc theo thứ tự, song song nhiệm vụ có thể phân phối công việc trên nhiều đơn vị xử lý. Một đơn vị xử lý có thể chịu trách nhiệm áp dụng bộ lọc làm mờ trong khi đơn vị khác áp dụng bộ lọc chỉnh sửa màu sắc, và cứ thế. Bằng cách thực hiện các nhiệm vụ này song song, ứng dụng có thể đạt được xử lý nhanh hơn và duy trì trải nghiệm người dùng mượt mà.

Lagrange’s @lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR) tận dụng tính song song dữ liệu và tác vụ để song song hóa hiệu quả và tạo ra các bằng chứng về tính toán phân tán trên các tập dữ liệu lớn. Trong giai đoạn bản đồ, tập dữ liệu đầu vào được phân vùng thành các phần nhỏ hơn và mỗi đoạn được xử lý độc lập bởi một công nhân lập bản đồ hoặc máy riêng biệt song song (song song nhiệm vụ). Hoạt động "bản đồ" có thể được song song trong mỗi tác vụ lập bản đồ trên nhiều lõi hoặc bộ xử lý (song song dữ liệu). Tương tự, trong giai đoạn giảm, thao tác "giảm" trên các giá trị được liên kết với mỗi khóa có thể được song song trong mỗi tác vụ giảm tốc (song song dữ liệu). Ngược lại, các tác vụ giảm tốc được thực hiện song song trên nhiều công nhân (song song nhiệm vụ).

Bằng cách kết hợp song song dữ liệu và song song nhiệm vụ, ZKMR có thể đạt được việc mở rộng và hiệu suất hiệu quả cho các tính toán phức tạp trên các bộ dữ liệu lớn trong khi duy trì các cam kết không biết thông qua việc sáng tạo chứng minh đệ quy.

Xác minh một thủ tục MapReduce tùy ý trong ZK từ Lagrange's “Giới thiệu ZK MapReduce”

Khả năng của Lagrange để tạo ra chứng minh lưu trữ cho các tính toán SQL trên @lagrangelabs/thông-báo-mạng-thử-nghiệm-euclid-cơ-sở-dữ-liệu-đáng-tin-cậy-đầu-tiên-của-ethereum-và-zk-coprocessor-cc4a5595365c">888,888 khe lưu trữ trong 1 phút và 20 giây cho thấy sức mạnh của ZKMR, cũng như sự song song của nhiệm vụ và dữ liệu mà nó được quyết định. Hơn nữa, gần đây của Lagrange Reckle Treesbài báo nhấn mạnh về sự cần thiết của sự song song trong việc đảm bảo rằng bằng chứng theo lô của dữ liệu trên chuỗi cũng có thể tính toán được trong 𝑂(log𝑛), độc lập với kích thước của lô.

Song song hóa sự nhất trí & thực thi

Mặc dù đoạn văn này không đề cập đến sự đồng thuận, các chuỗi khối cũng có thể song song hóa quá trình đồng thuận và thực thi. Các chuỗi khối truyền thống thường xử lý giao dịch theo thứ tự, đạt đồng thuận về các giao dịch của một khối (khối N) trước khi thực thi chúng. Xử lý song song của các giai đoạn đồng thuận và thực thi tăng đáng kể hiệu suất thực thi và là một kỹ thuật được minh họa bởi các hệ thống như Monad. Khi mạng đạt đồng thuận cho khối N, nó đồng thời thực thi các giao dịch cho khối trước đó (N-1).

Chiến lược này đảm bảo sử dụng liên tục và hiệu quả các tài nguyên tính toán, giảm thiểu hiện tượng không hoạt động và nâng cao khả năng xử lý giao dịch của mạng. Những cải tiến này tăng cường khả năng xử lý của hệ thống và chi phí vốn cần thiết để gửi thư rác vào mạng.

Phiên dịch viên & Giảm chi phí hoạt động

Khi hợp đồng thông minh được viết bằng các ngôn ngữ như Solidity, chúng được biên dịch thành bytecode cấp thấp trước. Sau đó, EVM sử dụng một trình thông dịch để thực thi bytecode này. Trình thông dịch đọc và thực thi mỗi hướng dẫn theo trình tự, tương tự như việc dịch một ngôn ngữ nước ngoài ngay lập tức khi nó đang được nói. Của Paradigm’s bài viết mới nhất về Rethnhấn mạnh rằng điều này dẫn đến chi phí quá mức vì mỗi hướng dẫn phải được xử lý một cách cá nhân và chuyển đổi từ bytecode sang các hướng dẫn máy trong quá trình thực thi.

Reth đang giải quyết hiệu suất không hiệu quả của EVM bằng cách tích hợp một trình biên dịch just-in-time (JIT). Trình biên dịch này chuyển đổi bytecode thành mã máy native ngay trước khi thực thi, tránh qua quá trình phiên dịch tốn tài nguyên thường cần thiết trong quá trình thực thi.

CổngBài báo Rethđề cập rằng 50% thời gian thực thi EVM dưới hệ thống dựa trên trình thông dịch được dành cho các quy trình mà JIT lý thuyết có thể tối ưu, gợi ý khả năng tăng tốc độ thực thi gấp đôi với việc triển khai JIT. Tuy nhiên, như Yilong đã chỉ ra trongbài thuyết trình này, trong khi JIT có thể giảm đáng kể thời gian cần thiết để xử lý các mã ghi cụ thể, nó có thể không ảnh hưởng mạnh mẽ đến việc thực thi tổng thể. Điều này bởi vì một phần đáng kể của 50% thời gian thực thi EVM mà JIT chiếm giữ liên quan đếncác hoạt động "host" và "system"(Trang 13), không thích hợp cho việc tối ưu hóa JIT như "toán học" hoặc "kiểm soát" do tính chất không tính toán của chúng.

Mặc dù trình thông dịch có thể giới hạn hiệu suất, nhưng chúng tạo cơ hội cho “dịch,” mở rộng phạm vi mã nguồn mà có thể tận dụng các máy ảo mới, giảm thiểu công việc mà các nhà phát triển phải sử dụng designer blockspace. Ví dụ, Movement Labs đã phát triển Fractal, cho phép các nhà phát triển triển khai các hợp đồng dựa trên Solidity trên MoveVM. Fractal hoạt động bằng cách biên dịch Solidity thành một Ngôn ngữ Trung gian chứa các hướng dẫn được miêu tả trong các mã opcode EVM, sau đó được ánh xạ vào các đối tác byte MoveVM của chúng, cho phép các hợp đồng Solidity chạy trong môi trường MoveVM.

Máy trạng thái Chuyên biệt & Tùy chỉnh

Tùy chỉnh lớp thực thi bao gồm thiết kế các máy trạng thái chuyên biệt được tối ưu hóa cho các ứng dụng cụ thể. Điều này không chỉ có nghĩa là một môi trường thực thi có thể từ bỏ hoàn toàn cần thiết cho máy ảo, mà còn cho phép các ứng dụng điều chỉnhbộ kiến trúc tập lệnh (ISA), cấu trúc dữ liệu và mô hình thực thi theo nhu cầu cụ thể của họ. Lợi ích hiệu suất chính của việc điều chỉnh ISA cho một ứng dụng cụ thể đến từ việc giảm chi phí dịch các mẫu tính toán của ứng dụng thành các hướng dẫn mục đích chung của ISA truyền thống. CPU đa năng sử dụng các tập lệnh cơ bản (ví dụ: thêm, tải, nhánh) để hỗ trợ chạy các loại phần mềm khác nhau. Tuy nhiên, khi các ứng dụng thường xuyên lặp lại các thao tác nhiều bước giống nhau, việc triển khai các mẫu này bằng cách sử dụng chuỗi các hướng dẫn đơn giản trở nên không hiệu quả.

Ví dụ, các ứng dụng cơ sở dữ liệu có thể cần phải liên tục duyệt qua cấu trúc dữ liệu cây, tìm kiếm các mục, cập nhật giá trị và cân bằng lại cây. Trên một CPU bình thường, ánh xạ những hoạt động cấp cao này yêu cầu phân rã chúng thành chuỗi dài các micro-op cấp thấp, như việc tải, lưu trữ, nhánh và phép tính, thực hiện từng cái một trên phần cứng chung. Ngược lại, một ISA được tùy chỉnh cho cơ sở dữ liệu có thể kết hợp những mẫu lặp lại này thành các hướng dẫn rộng tối ưu sử dụng phần cứng chuyên dụng. Một hướng dẫn “TraverseTree” có thể tính toán địa chỉ bộ nhớ, tải các nút liên quan và so sánh khóa bằng vi mạch so sánh song song được thiết kế cho hoạt động đó. “UpdateEntry” có thể trực tiếp thu thập mục từ bố trí lưu trữ cơ sở dữ liệu được tối ưu hóa, sửa đổi nó và xác nhận trạng thái mới tất cả trong một hướng dẫn duy nhất.

Điều này loại bỏ các đầu vào dư thừa từ việc dịch các hoạt động cấp cao xuống các hướng dẫn đơn giản. Nó cũng cho phép phần cứng thực hiện ứng dụng một cách tối ưu bằng cách sử dụng ít hơn nhưng rộng hơn, các hướng dẫn song song cụ thể phù hợp với nhu cầu của nó.

LayerN’s Norddemonstrates the performance benefits of specializing execution environments and data structures through their specific use case of a verifiable order book. LayerN’s approach focuses on optimizing the placement of trades into the order book data structure, while their pipelining mechanism is designed to efficiently insert new orders into the appropriate position within the order book’s data tree. By tailoring the data structure and insertion algorithm to the specific requirements of an order book, LayerN achieves low-latency order placement and high throughput.

Hoặc bạn có thể chuyển sang môi trường thi hành đa mục đích cho phép các mô-đun có thể lập trình tùy ý mà các ứng dụng có thể cắm vào để tối ưu hóa hiệu suất của họ. Cách tiếp cận này ưu tiên trải nghiệm của nhà phát triển hơn là hiệu suất thô.

Lưu loátvàCWDsử dụng một chiến lược cân bằng các sự đánh đổi giữa việc tối ưu hóa hiệu suất tính toán nguyên thủy và nâng cao trải nghiệm và tính tương thích của hệ sinh thái. Cách tiếp cận này tập trung vào việc sử dụng WebAssembly (Wasm) như máy ảo để thực thi mã. Wasm đã trở thành lựa chọn ưa thích trong phát triển web do việc hỗ trợ nhiều ngôn ngữ và mức độ phổ biến mà nó đã được áp dụng.

Quyết định của nhà phát triển sử dụng Wasm thay vì thực thi máy khách native phản ánh sự ưu tiên chiến lược cho tính linh hoạt và khả năng truy cập rộng rãi của môi trường thực thi đa dụng. Mặc dù thực thi native, chạy mã nguồn trực tiếp trên phần cứng mà không có máy ảo, có thể cung cấp hiệu suất tốt hơn, nhưng hạn chế tính tương thích qua nhiều nền tảng và ít tiếp cận hơn đối với nhà phát triển. Ngược lại, Wasm đảm bảo môi trường thực thi đồng nhất và an toàn trên các nền tảng khác nhau mặc dù không đạt được tốc độ tinh khiết như thực thi native. Sự đánh đổi này tương ứng với triết lý thiết kế của Fluent và CWD, ưu tiên năng suất phát triển và tích hợp hệ sinh thái rộng lớn hơn hiệu suất tối đa.

Triển khai CosmWasm (CWD), đặc biệt, minh họa phương pháp này không chỉ sử dụng Wasm để thực thi hợp đồng thông minh mà còn tích hợp nó vào một framework toàn diện hơn được thiết kế để hỗ trợ những phức tạp của hoạt động blockchain. Được làm giàu bởi “logic phụ,” framework này cung cấp quản lý tài khoản tiên tiến, cơ chế gas tùy chỉnh và sắp xếp giao dịch được tối ưu hóa. Những tính năng này đóng góp vào môi trường phát triển linh hoạt, hiệu quả và an toàn giúp các nhà phát triển xây dựng dapps có khả năng mở rộng và phức tạp một cách tương đối dễ dàng.

Stackr* tiếp cận khác bằng cách kết hợp những lợi ích của môi trường thực thi tùy chỉnh với sự linh hoạt của các nền tảng hợp đồng thông minh truyền thống. Stackr cho phép các nhà phát triển viết ứng dụng dưới dạng rollups, giúp họ xác định các quy tắc của riêng mình cho việc sắp xếp giao dịch, thực thi và cấu hình. Trong mô hình Stackr, các nhà phát triển có thể chọn ISA, cấu trúc dữ liệu và mô hình thực thi phù hợp nhất với yêu cầu của ứng dụng của họ.

Thiết kế micro-rollup của Stackr từ “Giới thiệu Stackr SDK”

Với Stackr, các nhà phát triển có thể áp dụng các quy tắc chuyển trạng thái trực tiếp trong thời gian chạy của ứng dụng thay vì bị ràng buộc bởi các quy tắc của một máy ảo đa năng, cho họ khả năng tinh chỉnh bộ chỉ thị của mình để hiệu quả hơn và định nghĩa lại bộ những điều có thể thực hiện được trong môi trường chạy.

Kết quả là việc thực thi trở nên nhẹ hơn và hiệu quả hơn, khi logic kinh doanh được thực hiện ở cấp độ khách hàng, loại bỏ nhu cầu cho việc triệu hồi và xác nhận hợp đồng thông minh đắt đỏ. Do đó, các khả năng xung quanh cách mà một ứng dụng được cấu hình mở rộng theo các loại ngôn ngữ, cấu trúc dữ liệu và chữ ký khác nhau mà các nhà phát triển có thể sử dụng cho một ứng dụng duy nhất mà không đánh đổi hiệu suất.

Kết luận

Có nhiều con đường đến hiệu suất lớp thực thi tối ưu.

Không có sự tối ưu hóa đơn lẻ nào cho việc truy cập vào trạng thái hoặc song song đứng ra như một điểm chủ yếu của sự khác biệt kỹ thuật giữa các lớp thực thi khi cố gắng bắt capture dapps. Khi chúng ta đi qua, những lợi ích của song song dựa trên tài nguyên trên Solana có thể được áp dụng tương đương cho mô hình UTXO của Fuel. Bất kỳ ai cũng có thể sử dụng Amazon’s các giải pháp sâu sắc để cải thiện khả năng mở rộng theo chiều ngang thông qua việc phân mảnhvà cải thiện hiệu suất lớp thực thi.

Trong khi hiệu suất lớp thực thi là một biến vector quan trọng để chiến thắng các nhà xây dựng ứng dụng phi tập trung, các L1s và L2s mới tập trung vào việc cải thiện việc thực thi phải cạnh tranh trên các biến khác, bao gồm an ninh, tương thích, và tính tương thích với công cụ hiện tại. Vì lý do này, sự phát triển của các lớp tương thích mới - từ Nebra đến Statenet đến AggLayer của Polygon - sẽ quan trọng đối với các nhà phát triển mua không gian khối thiết kế, vì họ có thể xây dựng hoặc mua không gian khối chuyên biệt mà không cần hy sinh tính đồng bộ của việc kết hợp và tính thanh khoản chung của các L1s đa mục đích truyền thống.

Cải thiện quản lý trạng thái và hiệu suất tính toán là tương quan lẫn nhau.

Trong cộng đồng thiết kế các lớp thực thi mới, việc song song hóa quyền truy cập trạng thái đã trở thành một biểu tượng định nghĩa cho những cải tiến về hiệu suất mà họ hứa hẹn mang lại. Mặc dù điều này là vì một lý do tốt, vì nó có thể dẫn đến một 5x cải thiện trong việc thực hiện của EVM, bằng chứng từ việc thử nghiệm song song sớm của Monad cho thấy vai trò của nó được nhấn mạnh quá nếu các cải tiến khác, như async I/O, không phát triển cùng mức.

Dựa trên điều này, chúng ta có thể kết luận rằng hiệu suất tính toán thường chỉ đạt được khi chúng ta cải thiện cách truy cập và lưu trữ trạng thái. Quản lý trạng thái hiệu quả giảm thời gian và tài nguyên cần thiết để truy cập và điều chỉnh dữ liệu, từ đó tăng tốc xử lý và giảm tải tính toán.

Điều này đưa ra một bước đi xa hơn, người đang chiếm ưu thế có thể đang đưa ra những quyết định phụ thuộc vào đường đi mà làm trở ngại cho khả năng cạnh tranh với những thiết kế blockchain mới mà tái kiến trúc cách trạng thái được quản lý và cập nhật, trong bối cảnh quán tính mà một cú nhảy cứng tạo ra. Do đó, các lớp thực thi chuyên biệt, modul và các L1 thay thế có thể tạo ra tính bảo vệ xung quanh những quyết định thiết kế cho việc lưu trữ trạng thái hiệu quả hơn và các giao thức để đọc và ghi từ đó. Những quyết định thiết kế này cung cấp một lợi thế cạnh tranh, vì người đang chiếm ưu thế có thể gặp phải quán tính trong việc cập nhật cấu trúc cơ sở dữ liệu mà không cần một cú nhảy cứng.

Vào cuối ngày, các giá trị của một blockspace ảnh hưởng đến không gian thiết kế cho các lớp thực thi.

Trong việc hiểu cách chúng ta có thể cải thiện các lớp thi hành, chúng ta có thể phân biệt rõ ràng rằng các lớp tối ưu hóa khác nhau tùy thuộc vào hai lựa chọn thiết kế quan trọng—ai đang thực hiện giao dịch, và cần bao nhiêu nút tham gia? Các kỹ thuật có sẵn cho các nhà phát triển giải quyết các vấn đề chậm thi hành khác nhau đáng kể tùy thuộc vào câu trả lời ban đầu của một nhóm đối với những câu hỏi này.

Một mặt, các L1 monolithic như Solana và Monad không chấp nhận việc tách vai trò của người xác minh thành các nút mạnh mẽ và yếu không đồng nhất để tăng tốc hiệu suất. Việc "chấp nhận" sự phình toàn bộ lưu trữ trong thời gian ngắn không phải là một giải pháp khả thi, vì vậy họ dựa vào cải tiến tại tầng cơ sở dữ liệu và các thành phần khác của động cơ sản xuất khối, như sự đồng thuận, để đền bù cho số lượng nút thực thi rộng hơn được coi là một thành phần quan trọng và giá trị cốt lõi của mạng lưới. Bởi vì mô hình bảo mật của các L1 này phụ thuộc vào sự đồng thuận của một tập hợp người xác minh phân tán hơn với yêu cầu phần cứng yếu hơn, dữ liệu của họ cần được ghi vào một cơ sở dữ liệu ở trên đĩa, điều này cần thiết rẻ hơn cho một blockchain phi quyền lực và tối đa hóa phân tán.

Trong khi đó, các dự án như Ethereum và các L2 của nó đang theo đuổi một lộ trình hướng đến trung tâm hóa trên các nút thực thi của họ thông qua các nhà xây dựng khối trung tâm phải chịu trách nhiệm đối với các nút đề xuất xác minh yếu hơn thông qua bằng chứng gian lận hoặc tính hợp lệ.

Giả sử "người thực thi" tập trung của các giao dịch và chuyển đổi trạng thái được coi là chấp nhận được trong việc theo đuổi một tương lai phi tập trung. Trong trường hợp đó, định luật vật lý nói rằng các hệ thống có thể 1) thêm các khối vào một chuỗi mà không yêu cầu nhiều tác nhân thực hiện lại các giao dịch, 2) tăng yêu cầu trình xác thực để tối đa hóa tính toán trong bộ nhớ (và bỏ qua vấn đề phình to trạng thái) và 3) giảm độ trễ và tắc nghẽn đồng thuận rõ ràng giành chiến thắng so với các hệ thống dựa trên sự phân cấp và đồng thuận rộng rãi giữa các nút.

Trong việc tìm kiếm sự cân bằng giữa khả năng mở rộng và việc giảm thiểu sự tin cậy, trở nên rõ ràng rằng mục tiêu của các lớp thực thi không nên tối ưu hóa cho sự phân quyền mù quáng, cũng không nhất thiết lúc nào thực thi cũng phải hoàn toàn không cần sự cho phép.

Khi chúng tôi phát triển và triển khai một loạt các công cụ mật mã rộng lớn hơn, chẳng hạn như chứng minh tính hợp lệ và chống gian lận, chúng tôi hiệu quả giảm số lượng nút cần thiết để chống lại sự kiểm duyệt và duy trì an toàn và tính sống còn. Tuy nhiên, phương pháp này liên quan đến sự đánh đổi, có thể ảnh hưởng đến khả năng chống kiểm duyệt, tính nguyên vẹn của thứ tự và cam kết về tính sống còn do sự tập trung có thể xảy ra của các thực thi.

Như đã chú ý bởi Sreeram, thuật ngữ “decentralization tối thiểu” không có nghĩa là “việc xác nhận nên không cần sự cho phép” mà là “chỉ cần đúng cách khuyến khích.” Điều này ngụ ý rằng một hệ thống được giám sát cẩn thận, nơi mà những người xác nhận phải đối mặt với hậu quả đáng kể nếu có hành vi không đúng, có thể duy trì sự an toàn và tính sống còn mà không cần sự phân quyền quá mức (.h/t Sreeram).

Các mô hình quản trị như vậy đã được thử nghiệm trong các ứng dụng thực tế. Ví dụ, các rollups như Arbitrum đang khám phá các hệ thống quản trị dựa trên ủy ban để áp dụng các quy tắc sắp xếp giao dịch và chọn lựa lãnh đạo, và họ đang xem xét các cơ chế mà sequencers sử dụng dữ liệu trên chuỗi để duy trì các chính sách sắp xếp giao dịch.

Bất chấp những tiến bộ này, không có "biên giới tối ưu pareto" dứt khoát để cân bằng phân cấp với hiệu suất.

Các yếu tố mang tính chất ý thức và kỹ thuật tiếp tục ủng hộ việc phân quyền các nút thực thi để xác minh trạng thái. Trong khi việc tập trung các nút giảm bớt chi phí đồng thuận và nâng cấp phần cứng có thể cải thiện đáng kể hiệu suất, vẫn còn chưa rõ liệu những tối ưu hóa này có thu hút các nhà phát triển tập trung vào việc tạo ra các ứng dụng chống kiểm duyệt và độ chống kiểm duyệt sẽ còn là giá trị cốt lõi trong ngành hay không.

*được dấu* một công ty trong danh mục mẫu

Disclaimer：

1. Bài viết này được tái bản từ [GategươngChuyển tiếp tiêu đề ban đầu 'Designer Blockspace: Tương lai của môi trường thực thi', Tất cả bản quyền thuộc về tác giả ban đầuBenjamin Funk]. Nếu có ý kiến phản đối về việc tái in 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ừ Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không hề đại diện cho bất kỳ lời khuyên đầu tư nào.

3. Bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.