EVM của Ethereum phải đối mặt với các vấn đề nghiêm trọng về hiệu suất do kiến trúc đơn luồng, đặc biệt là khi xử lý các giao dịch đồng thời cao. Phương thức thực thi nối tiếp này giới hạn thông lượng của mạng, khiến tốc độ xử lý không thể đáp ứng được nhu cầu ngày càng tăng của người dùng. Bằng cách phân tích từng bước toàn bộ quá trình thực thi nối tiếp EVM, chúng tôi đã phát hiện ra hai vấn đề phần mềm chính để Ethereum đạt được thực thi song song: 1. Nhận dạng trạng thái 2. Kiến trúc dữ liệu và mức tiêu thụ IPOS, mỗi công ty đều có giải pháp riêng. các giải pháp của riêng mình và phải đối mặt với nhiều sự đánh đổi, bao gồm cả việc chúng có tương thích với EVM hay không, xác định xem nên sử dụng song song lạc quan hay bi quan, kiến trúc dữ liệu của cơ sở dữ liệu, nên sử dụng các kênh đồng thời cao hiệu quả về bộ nhớ hay đĩa cứng hơn, kinh nghiệm phát triển của nhà phát triển và các yêu cầu về phần cứng, kiến trúc chuỗi mô-đun hoặc nguyên khối, tất cả đều đáng được cân nhắc cẩn thận.
Chúng tôi cũng nhận thấy rằng mặc dù việc thực thi song song dường như mở rộng chuỗi khối theo cấp số nhân nhưng nó vẫn có những điểm nghẽn cổ chai này vốn có trong các hệ thống phân tán, bao gồm các vấn đề như mạng P2P và thông lượng của chính cơ sở dữ liệu. Điện toán chuỗi khối vẫn còn một chặng đường dài trước khi có thể đạt được sức mạnh tính toán của máy tính truyền thống. Hiện tại, bản thân việc thực thi song song cũng phải đối mặt với một số vấn đề, bao gồm yêu cầu phần cứng ngày càng cao để thực thi song song, rủi ro tập trung và kiểm duyệt do các nút ngày càng chuyên biệt mang lại và thiết kế cơ chế dựa trên bộ nhớ, các cụm hoặc nút trung tâm cũng sẽ Mang đến nguy cơ ngừng hoạt động, đồng thời, giao tiếp xuyên chuỗi giữa các chuỗi khối song song cũng sẽ là một vấn đề. Điều này vẫn đáng để nhiều đội khám phá hơn.
Từ kiến trúc của mỗi công ty và suy nghĩ về khả năng tương thích EVM, chúng tôi biết rằng sự đổi mới mang tính đột phá đến từ sự không khoan nhượng trong quá khứ. Công nghệ chuỗi khối vẫn còn ở những ngày đầu và những cải tiến về hiệu suất còn lâu mới kết thúc.
Vấn đề đơn luồng của Ethereum
Ethereum EVM luôn bị chỉ trích về hiệu suất, chủ yếu là do thiết kế kiến trúc lạc hậu, trong đó vấn đề không hỗ trợ song song hóa là vấn đề nghiêm trọng nhất. Để song song hóa giao dịch, việc này tương đương với việc biến một con đường thành nhiều đường băng, điều này có thể mang lại những cải thiện theo cấp số nhân cho lưu lượng giao thông có thể đáp ứng trên đường.
Đi sâu hơn vào Ethereum, dựa trên nền tảng của sự tách biệt hiện tại giữa lớp thực thi và lớp đồng thuận, chúng ta sẽ thấy rằng tất cả quá trình xử lý giao dịch của EVM đều được thực hiện nối tiếp.
Quá trình thực hiện giao dịch của Ethereum
Trong giao dịch Ethereum, trước tiên người dùng gửi giao dịch đến Mempool thông qua RPC, sau đó Người xây dựng chọn giao dịch tối đa hóa lợi nhuận và sắp xếp giao dịch đó. Tại thời điểm này, thứ tự của các giao dịch đã được xác định. Người đề xuất phát giao dịch đến lớp đồng thuận và lớp đồng thuận xác định tính hợp lệ của khối, chẳng hạn như từ một người gửi hợp lệ trong khối được gửi đến lớp thực thi dưới dạng tải thực thi và lớp thực thi sẽ thực thi giao dịch. Quá trình thực hiện giao dịch ngắn gọn như sau: (Lấy Alice gửi 1 ETH cho Bob làm ví dụ)
1. Trong EVM của nút thực thi, nó sẽ chuyển đổi lệnh giao dịch NO.0 thành mã OPcode mà EVM có thể nhận ra.
2. Sau đó, xác định Gas cần thiết cho giao dịch này dựa trên mã hóa cứng OPcode.
3. Trong quá trình thực hiện giao dịch, bạn cần truy cập vào cơ sở dữ liệu để lấy trạng thái số dư của Alice và Bob, sau đó thực hiện opcode giao dịch để biết rằng số dư của Alice là âm một và số dư của Bob là cộng một và ghi/cập nhật trạng thái số dư này vào cơ sở dữ liệu.
4. Từ khối, lấy giao dịch số 1 ra và tiếp tục thực hiện tuần tự theo vòng lặp cho đến khi giao dịch của khối hoàn tất.
5. Dữ liệu trong cơ sở dữ liệu chủ yếu được lưu trữ dưới dạng số Merkel, sau khi tất cả các giao dịch trong khối cuối cùng được thực hiện theo trình tự, gốc trạng thái (lưu trữ trạng thái tài khoản), gốc giao dịch (lưu trữ thứ tự giao dịch) và biên nhận trong cơ sở dữ liệu Gốc (lưu trữ thông tin ngẫu nhiên về giao dịch, chẳng hạn như trạng thái thành công và phí gas) được gửi đến lớp đồng thuận.
6. Lớp đồng thuận có thể dễ dàng chứng minh tính xác thực của giao dịch sau khi nhận được trạng thái gốc. Lớp thực thi truyền dữ liệu xác minh trở lại lớp đồng thuận và khối hiện được coi là đã được xác minh.
7. Lớp đồng thuận thêm khối vào phần đầu của blockchain của chính nó và chứng minh nó, phát sóng bằng chứng qua mạng.
Đây là toàn bộ quá trình bao gồm việc thực hiện tuần tự các giao dịch trong khối. Lý do chính là mỗi giao dịch có NO riêng và mỗi giao dịch có thể cần đọc trạng thái trong cơ sở dữ liệu và viết lại trạng thái. Nếu chúng không được thực hiện tuần tự sẽ dẫn đến xung đột trạng thái vì một số giao dịch phụ thuộc vào trạng thái của nhau. Vì vậy, đây là lý do tại sao MEV chọn thực hiện nối tiếp.
Sự đơn giản của MEV cũng có nghĩa là việc thực thi nối tiếp mang lại hiệu suất cực thấp, đó là một trong những lý do chính khiến Ethereum chỉ có TPS hai chữ số. Trong bối cảnh phát triển hiện tại tập trung vào các ứng dụng tiêu dùng, EVM, với tư cách là một mô hình thiết kế lạc hậu, phải đối mặt với các vấn đề về hiệu suất cần được cải thiện khẩn cấp. Mặc dù EVM hiện tại đã chuyển sang lộ trình hoàn toàn lấy Lớp 2 làm trung tâm, nhưng các vấn đề về EVM của nó, chẳng hạn như. cấu trúc trie MPT và sự kém hiệu quả của cơ sở dữ liệu như LevelDB, v.v., cần được giải quyết khẩn cấp.
Khi vấn đề này phát triển, nhiều dự án đã bắt đầu xây dựng các EVM hiệu suất cao song song để giải quyết mô hình thiết kế cũ của Ethereum. Thông qua quy trình EVM, chúng ta có thể thấy rằng có hai vấn đề chính được giải quyết bằng EVM hiệu suất cao:
1. Tách biệt trạng thái giao dịch: Do phụ thuộc lẫn nhau về trạng thái nên các giao dịch cần được thực hiện tuần tự, các giao dịch có trạng thái độc lập cần được tách biệt, những giao dịch phụ thuộc vẫn cần được thực hiện tuần tự. Sau đó, nó có thể được phân phối tới nhiều lõi để xử lý song song.
2. Cải thiện kiến trúc cơ sở dữ liệu: Ethereum sử dụng cây MPT. Vì một giao dịch bao gồm một số lượng lớn các hoạt động đọc, nên thông thường điều này sẽ dẫn đến các hoạt động đọc và ghi cơ sở dữ liệu cực kỳ cao, tức là yêu cầu IOPS (IO Per Second) cực cao. SSD cấp độ người tiêu dùng thông thường không thể đáp ứng nhu cầu này.
Nhìn chung, trong các giải pháp xây dựng blockchain phổ thông hiện nay, việc tối ưu hóa phần mềm thường chủ yếu là tách trạng thái giao dịch để xây dựng các giao dịch song song và tối ưu hóa cơ sở dữ liệu để hỗ trợ đọc trạng thái giao dịch đồng thời ở mức độ cao. Cùng với nhu cầu về hiệu năng cao, yêu cầu về phần cứng của hầu hết các dự án cũng ngày càng tăng cao. Ethereum luôn rất thận trọng trong việc mở rộng hiệu suất của Lớp 1, bởi vì nó đồng nghĩa với việc tập trung hóa và không ổn định. Tuy nhiên, EVM hiệu suất cao hiện tại thường từ bỏ những xiềng xích này và đưa ra những cải tiến phần mềm vượt trội, tối ưu hóa mạng P2P, tái thiết cơ sở dữ liệu và phần cứng chuyên nghiệp cấp doanh nghiệp.
Các vấn đề về IOPS của cơ sở dữ liệu phái sinh
Việc xác định và phân tách thực thi song song thực ra không khó hiểu. Khó khăn chính và ít được thảo luận công khai là vấn đề IOPS của cơ sở dữ liệu. Trong bài viết này, chúng tôi cũng sẽ sử dụng các ví dụ thực tế để người đọc cảm nhận được những vấn đề phức tạp mà cơ sở dữ liệu blockchain gặp phải.
Trong Ethereum, nút đầy đủ thực sự được cài đặt với một máy ảo, có thể được coi là máy tính thông thường của chúng ta và dữ liệu của chúng ta được lưu trữ trong phần mềm - cơ sở dữ liệu chuyên nghiệp. Sử dụng phần mềm này để quản lý dữ liệu khổng lồ. Dữ liệu của các ngành khác nhau có nhu cầu khác nhau đối với các loại cơ sở dữ liệu khác nhau. Ví dụ: cơ sở dữ liệu vectơ rất phổ biến trong các lĩnh vực như AI, nơi có nhiều loại dữ liệu. Trong lĩnh vực blockchain, chẳng hạn như Ethereum, cơ sở dữ liệu Cặp khóa-giá trị tương đối đơn giản được sử dụng.
Sơ đồ tổ chức dữ liệu Ethereum, nguồn: Github
Thông thường dữ liệu trong cơ sở dữ liệu được tổ chức cùng nhau theo cách trừu tượng và Ethereum ở dạng cây MPT. Trạng thái dữ liệu cuối cùng của cây MPT sẽ tạo thành nút gốc. Nếu có bất kỳ dữ liệu nào thay đổi, nút gốc sẽ thay đổi. Do đó, việc sử dụng MPT có thể dễ dàng xác minh tính toàn vẹn của dữ liệu.
Hãy đưa ra một ví dụ để cảm nhận mức tiêu thụ tài nguyên của cơ sở dữ liệu hiện tại:
Trong Cây Merkle Patricia (MPT) k-fork có n nút lá, việc cập nhật một cặp khóa-giá trị yêu cầu thao tác đọc O(klog kn) và thao tác ghi O(log kn). Ví dụ: đối với MPT nhị phân có 16 tỷ khóa (tức là 1 TB trạng thái blockchain), điều này tương đương với khoảng 68 thao tác đọc và 34 thao tác ghi. Giả sử rằng blockchain của chúng tôi muốn xử lý 10.000 giao dịch chuyển khoản mỗi giây và cần cập nhật ba khóa-giá trị trong cây trạng thái Tổng cộng là 10.000 x 3 x 68 = 2.040.000 lần, tức là 2 M IOPS (I/O Per). Thứ hai) hoạt động (trong thực tế, nó có thể được giảm xuống một mức độ lớn thông qua nén và lưu vào bộ nhớ đệm, xuống còn khoảng 200.000 IOPS và chúng tôi không mở rộng). Các ổ SSD tiêu dùng lớn hiện nay đơn giản là không thể hỗ trợ điều này (Intel Optane DC P 580 0X 800 GB chỉ là 100.000 IOPS).
Cây MPT hiện đang phải đối mặt với một số vấn đề, bao gồm:
● Vấn đề về hiệu suất: Do cấu trúc cây phân cấp, MPT thường cần duyệt qua nhiều nút khi cập nhật dữ liệu. Mỗi cập nhật trạng thái (chẳng hạn như chuyển khoản hoặc thực hiện hợp đồng thông minh) yêu cầu một lượng lớn phép tính băm và hiệu suất thấp do cần truy cập vào nhiều lớp nút.
● Mở rộng trạng thái: Theo thời gian, dữ liệu trạng thái như hợp đồng thông minh và số dư tài khoản trên blockchain sẽ tiếp tục tăng, khiến kích thước của cây MPT tiếp tục mở rộng. Điều này sẽ dẫn đến việc các nút cần lưu trữ ngày càng nhiều dữ liệu, đặt ra thách thức đối với không gian lưu trữ và các nút đồng bộ hóa.
Mở rộng trạng thái Ethereum (liên quan đến việc cắt tỉa trạng thái), nguồn: Etherscan
● Không có khả năng xử lý cập nhật một phần một cách hiệu quả: Khi một nút lá trong cấu trúc cây thay đổi, các nút dọc theo toàn bộ đường dẫn sẽ bị ảnh hưởng. Ethereum MPT cần tính toán lại tất cả các giá trị băm từ nút lá đến nút gốc, điều này khiến ngay cả những thay đổi trạng thái cục bộ cũng cần được cập nhật trên một số lượng lớn nút, do đó ảnh hưởng đến hiệu suất.
Chúng ta có thể thấy rằng Ethereum hiện đang phải đối mặt với nhiều vấn đề khác nhau theo MPT và nó cũng đã đề xuất nhiều giải pháp khác nhau, chẳng hạn như cắt tỉa trạng thái để mở rộng trạng thái và xây dựng Cây Verkel mới cho các vấn đề về hiệu suất MPT. Bằng cách xây dựng cơ sở dữ liệu cấu trúc Verkel Tree mới, giảm độ sâu của cây để giảm số lượng truy cập cơ sở dữ liệu trong quá trình cập nhật một phần và sử dụng các cam kết vectơ (chủ yếu là các cam kết KZG) để giảm kích thước của bằng chứng và số lượng truy cập cơ sở dữ liệu.
Nói tóm lại, cây MPT trước đây đã quá cũ và phải đối mặt với nhiều thách thức mới, do đó, việc thay đổi cách lưu trữ dữ liệu, chẳng hạn như sử dụng cây Verkel, đã được đưa vào lộ trình của nó. Nhưng đây chỉ là một sửa đổi rất yếu và nó vẫn không liên quan đến việc thực thi song song cũng như giải pháp cho IOPS cao được yêu cầu trong điều kiện đồng thời cao.
Chuỗi công khai mới đạt tiêu chuẩn với khả năng thực thi song song
Như chúng tôi đã nói ở phần trước, thực hiện song song có nghĩa là chuyển từ một làn sang nhiều làn tại các giao lộ nhiều làn, một phần mềm trung gian, chẳng hạn như điều phối đèn giao thông, thường được yêu cầu gửi thông tin để mỗi làn có thể đi qua thuận lợi. Điều này cũng đúng với blockchain. Trong các giao dịch song song, chúng ta cần chuyển các giao dịch của người dùng thông qua phần mềm trung gian xác định trạng thái để có thể tách các giao dịch với các trạng thái không liên quan nhằm đạt được TPS cao do thực thi song song mang lại cũng có nghĩa là IOPS lớn. yêu cầu đối với cơ sở dữ liệu cơ bản. Hầu như tất cả các Lớp 1 mới đều có tính năng thực thi song song như một tính năng tiêu chuẩn.
Có nhiều cách để phân loại các giải pháp thực thi song song Theo máy ảo cơ bản, chúng được chia thành EVM (Sei, MegaETH, Monad) và None-EVM (Solana, Aptos, Sui). Theo phương pháp tách trạng thái giao dịch, nó có thể được chia thành thực hiện lạc quan (giả sử rằng tất cả các giao dịch không muốn được thực hiện và nếu trạng thái xung đột, phần giao dịch này sẽ được khôi phục và thực hiện lại) và sớm khai báo (người phát triển cần khai báo dữ liệu trạng thái truy cập trong chương trình). Những phân loại này cũng hàm ý sự đánh đổi.
Tiếp theo, chúng tôi sẽ không phân chia dựa trên việc đó có phải là EVM hay không mà chỉ so sánh những cải tiến trong việc phân tách trạng thái và cơ sở dữ liệu của từng chuỗi công khai.
MegaETH
MegaETH hoàn toàn là một blockchain không đồng nhất với mục tiêu chính là hiệu suất, dựa vào tính bảo mật của Ethereum bằng cách sử dụng EigenDA làm lớp đồng thuận và lớp DA. Là lớp thực thi, nó sẽ tối đa hóa hiệu suất phần cứng và cải thiện TPS.
Có ba loại phương pháp tối ưu hóa để xử lý giao dịch:
1. Tách trạng thái: Xây dựng khối luồng theo mức độ ưu tiên giao dịch. Mô hình này tương tự như POS của Solana. Trên thực tế, các giao dịch của Solana cũng được xây dựng theo mô hình streaming nhưng Solana không có ưu tiên và tất cả đều cạnh tranh về tốc độ. Và MegaETH muốn có thể xây dựng một số loại thuật toán ưu tiên cho các giao dịch.
2. Cơ sở dữ liệu: Để giải quyết vấn đề của MPT Trie, nó đã xây dựng cấu trúc dữ liệu mới để cung cấp IOPS cao hơn. Khi kiểm tra cơ sở mã của MegaETH, chúng tôi nhận thấy rằng nó cũng tham chiếu đến phương pháp thiết kế của Verkel Trie.
3. Chuyên môn hóa phần cứng: Bằng cách tập trung và chuyên biệt hóa bộ phân loại, tính toán trong bộ nhớ được triển khai để cải thiện đáng kể hiệu quả IO.
Trên thực tế, MegaETH hy vọng sẽ giao phó khả năng chống bảo mật và kiểm duyệt cho Ethereum ở Lớp 2, để nó có thể tối ưu hóa các nút ở mức tối đa và đảm bảo rằng trình sắp xếp chuỗi không làm điều ác thông qua tính bảo mật kinh tế của POS. Có rất nhiều điểm đáng giá ở đây. Nhưng chúng tôi không mở rộng. Mặc dù MegaETH đang xây dựng các giao dịch để thực thi song song nhưng trên thực tế, nó hiện không triển khai thực thi song song. Nó hy vọng sẽ tối đa hóa hiệu suất của một nút sắp xếp duy nhất để mở rộng hiệu suất với phần cứng ở mức độ lớn nhất và sau đó mở rộng hiệu suất thông qua thực thi song song.
Đơn nguyên
Không giống như MegaETH, Monad là một chuỗi riêng biệt, đáp ứng hai điểm quan trọng mà chúng tôi đã giới thiệu là cần được tối ưu hóa để thực thi song song, phân tách trạng thái thực thi song song và tái cấu trúc cơ sở dữ liệu. Chúng tôi mô tả ngắn gọn các phương pháp cụ thể được Monad sử dụng:
● Thực thi song song lạc quan: Để nhận dạng giao dịch, trạng thái mặc định cổ điển nhất của tất cả các giao dịch là không bị đóng. Khi gặp xung đột trạng thái, phương thức này hiện được sử dụng trong cơ chế Block-STM của Aptos. . Hoạt động tuyệt vời.
● Xây dựng lại cơ sở dữ liệu: Để cải thiện IOPS của cơ sở dữ liệu, Monad xây dựng lại cấu trúc dữ liệu tương thích EVM MPT (Merkel Patricia Tree). Monad triển khai cấu trúc dữ liệu tương thích với Cây Patricia và hỗ trợ I/O không đồng bộ của cơ sở dữ liệu mới nhất, có thể Hỗ trợ đọc một trạng thái nhất định mà không cần đợi hoàn thành việc ghi vào dữ liệu.
● Thực thi không đồng bộ: Trên Ethereum, mặc dù chúng tôi xác định nghiêm ngặt lớp đồng thuận và lớp thực thi cụ thể, nhưng chúng tôi nhận thấy rằng lớp đồng thuận và lớp thực thi (khác với khái niệm Lớp 2 là lớp thực thi), ở đây đề cập đến Ethereum vẫn cần Các nút thực thi (để thực hiện các giao dịch trên Ethereum) vẫn được kết hợp với nhau và việc thực thi sẽ cung cấp cho Merkel Root được cập nhật sau khi thực hiện về sự đồng thuận, để lớp đồng thuận có thể bỏ phiếu để đạt được sự đồng thuận. Các đơn nguyên coi trạng thái đã được giải quyết ngay khi quá trình phân loại hoàn tất, do đó chỉ cần có sự đồng thuận về các giao dịch được sắp xếp, thậm chí không cần thực hiện để tiết lộ kết quả này. Ý tưởng này cho phép Monad tách biệt khéo léo lớp đồng thuận và lớp thực thi để đạt được việc thực thi đồng thuận đồng thời. Các nút có thể thực hiện các giao dịch trong khối N-1 trong khi vẫn duy trì biểu quyết đồng thuận trên khối N.
Tất nhiên, Monad cũng có nhiều công nghệ khác, bao gồm thuật toán đồng thuận mới MonadBFT, cùng nhau xây dựng EVM Lớp 1 song song hiệu suất cao.
Aptos
Aptos đã được tách ra khỏi nhóm Diem của Facebook. It và Sui được coi là bộ đôi Move. Tuy nhiên, do sự không thống nhất về khái niệm kỹ thuật giữa cả hai nên ngôn ngữ Move hiện tại của cả hai đã trở nên rất khác nhau. Aptos Nó bám sát hơn thiết kế ban đầu của Diệm và Tùy đã có những thay đổi mạnh mẽ về thiết kế.
Các vấn đề cần giải quyết để thực hiện song song:
● Nhận dạng trạng thái: Thực thi song song lạc quan. Aptos đã phát triển công cụ thực thi song song Block-STM, thực thi các giao dịch một cách lạc quan theo mặc định. Nếu gặp phải xung đột trạng thái, nó sẽ được thực thi lại. Hiện tại, công nghệ này đã được chấp nhận rộng rãi, chẳng hạn như Polygon, Monad, Sei và StarkNet đều sử dụng công nghệ này.
● Cải tiến IO: Block-STM sử dụng cấu trúc dữ liệu nhiều phiên bản để tránh xung đột trạng thái. Ví dụ: giả sử những người còn lại trong chúng ta đang viết cơ sở dữ liệu. Thông thường, chúng ta sẽ không thể truy cập nó vì cần tránh xung đột dữ liệu, nhưng cấu trúc dữ liệu nhiều phiên bản có thể cho phép chúng ta truy cập các phiên bản trước đây. Vấn đề là giải pháp này sẽ tiêu tốn rất nhiều tài nguyên vì bạn cần tạo một phiên bản hiển thị cho mỗi luồng.
● Thực thi không đồng bộ: Tương tự như Monad, việc truyền giao dịch, đặt hàng giao dịch, thực hiện giao dịch, lưu trữ trạng thái và xác minh khối đều được thực hiện đồng thời.
Hiện tại, Block-STM đã được hầu hết các chuỗi công khai chấp nhận và Monad cho biết nhờ sự xuất hiện của công nghệ này, nó có thể giảm bớt áp lực cho các nhà phát triển một cách hiệu quả. Tuy nhiên, vấn đề mà Aptos phải đối mặt là trí thông minh của Block-STM đã có. gây ra Vấn đề yêu cầu nút quá mức đòi hỏi phải có phần cứng chuyên dụng và tập trung để giải quyết vấn đề này.
Tùy
Tùy, giống như Aptos, được kế thừa từ dự án Diệm. Ngược lại, Sui sử dụng phương pháp song song bi quan, xác minh nghiêm ngặt sự phụ thuộc trạng thái giữa các giao dịch và sử dụng cơ chế khóa để ngăn xung đột trong quá trình thực thi. Aptos hy vọng sẽ giảm bớt gánh nặng phát triển cho các nhà phát triển.
● Nhận dạng trạng thái: Không giống như Aptosb, tính năng song song bi quan được áp dụng, vì vậy các nhà phát triển cần khai báo quyền truy cập trạng thái của riêng họ, thay vì để lại nhận dạng trạng thái song song cho hệ thống xử lý, điều này làm tăng gánh nặng phát triển của nhà phát triển và giảm độ phức tạp của thiết kế hệ thống. tăng khả năng song song.
● Cải tiến IO: Cải tiến IO hiện chủ yếu là cải tiến mô hình. Ethereum sử dụng mô hình dựa trên tài khoản và mỗi tài khoản duy trì dữ liệu của nó. Tuy nhiên, Sui sử dụng cấu trúc của Đối tượng thay vì mô hình tài khoản. ảnh hưởng đến sự khó khăn của việc thực hiện song song với hiệu suất cao nhất.
Bởi vì Sui không có di sản lịch sử về EVM và không có vấn đề về khả năng tương thích nên nó đã thực hiện những thay đổi mạnh mẽ dựa trên hệ thống Move. Đối với mô hình tài khoản, nó cũng đề xuất các ý tưởng đổi mới Đối tượng. Loại đổi mới này ở cấp độ trừu tượng thực sự khó hơn. Tuy nhiên, mô hình Đối tượng của nó mang lại nhiều lợi ích cho việc xử lý song song cũng chính vì mô hình Đối tượng mà nó xây dựng một kiến trúc mạng rất độc đáo mà về mặt lý thuyết có thể mở rộng vô hạn.
Solana - Vũ công lửa
Solana được coi là người tiên phong trong lĩnh vực điện toán song song. Triết lý của Solana luôn là các hệ thống blockchain sẽ phát triển cùng với sự tiến bộ của phần cứng. Sau đây là phương pháp xử lý song song hiện tại của Solana:
● Nhận dạng trạng thái: Giống như SUI, Solana cũng sử dụng tính song song xác định, xuất phát từ kinh nghiệm trước đây của Anatoly trong việc xử lý các hệ thống nhúng, trong đó tất cả các trạng thái thường được khai báo trước. Điều này cho phép CPU biết tất cả các phần phụ thuộc, cho phép nó tải trước các phần bộ nhớ cần thiết. Kết quả là việc thực thi hệ thống được tối ưu hóa, nhưng một lần nữa, nó đòi hỏi các nhà phát triển phải thực hiện thêm công việc ngay từ đầu. Trên Solana, tất cả các phần phụ thuộc bộ nhớ của một chương trình đều được yêu cầu và khai báo trong giao dịch được xây dựng (tức là danh sách truy cập), cho phép bộ thực thi lập lịch và thực hiện song song nhiều giao dịch một cách hiệu quả.
● Cơ sở dữ liệu: Solana đã sử dụng Cloudbreak để xây dựng cơ sở dữ liệu tài khoản tùy chỉnh của riêng mình, sử dụng các tài khoản làm mô hình. Dữ liệu tài khoản được phân phối trên nhiều phân đoạn, tương tự như việc chia thư viện thành nhiều lớp và có thể dựa trên điều đó. tăng hoặc giảm số lớp để cân bằng tải. Nó sẽ được ánh xạ tới bộ nhớ trên SSD, do đó SSD có thể được vận hành nhanh chóng thông qua bộ nhớ thông qua thiết kế đường ống. Nó cũng hỗ trợ truy cập song song vào nhiều dữ liệu và có thể xử lý song song 32 thao tác IO cùng một lúc.
Solana yêu cầu các nhà phát triển khai báo trạng thái mà họ cần truy cập thông qua tính song song xác định. Điều này thực sự giống với tình huống thay đổi truyền thống. Về mặt xây dựng chương trình, các nhà phát triển cần tự xây dựng các ứng dụng song song, trong khi lập kế hoạch chương trình và tính song song không đồng bộ của đường dẫn thời gian chạy là những gì cần có. dự án cần xây dựng. Về cơ sở dữ liệu, nó xây dựng DataBase riêng để song song hóa dữ liệu nhằm cải thiện IPOS.
Đồng thời, Firedancer, khách hàng của các phiên bản Solana tiếp theo, được thúc đẩy và phát triển bởi Jump Trading, một gã khổng lồ về định lượng với năng lực kỹ thuật rất mạnh. Nó có cùng tầm nhìn với Solana, với mục tiêu loại bỏ sự thiếu hiệu quả của phần mềm và nâng cao hiệu suất. giới hạn phần cứng. Những cải tiến của nó chủ yếu nhằm mục đích cải thiện phần cứng cơ bản, bao gồm truyền bá P2P, xử lý song song dữ liệu SIMD phần cứng, v.v. Điều này rất giống với ý tưởng của MegaETH.
Sei
Sei hiện đang sử dụng
● Thực thi song song lạc quan: Được tham chiếu từ thiết kế Block-STM của Aptos. Phiên bản Sei V1 sử dụng sơ đồ song song thụ động tương tự như Sui và Solana, yêu cầu các nhà phát triển khai báo các đối tượng họ sử dụng. Tuy nhiên, sau Sei V2, nó đã được thay đổi thành sơ đồ song song lạc quan của Aptos. Điều này sẽ giúp ích cho Sei, công ty có thể thiếu nhà phát triển và có thể dễ dàng di chuyển các hợp đồng khỏi hệ sinh thái EVM hơn.
Thiết kế SeiDB, nguồn: Sei
● SeiDB: Toàn bộ giải pháp cơ sở dữ liệu được xây dựng dựa trên đề xuất ADR-065 của Cosmos. Thực thể của nó sử dụng PebbleDB. Cấu trúc dữ liệu được thiết kế để phân chia dữ liệu thành dữ liệu hoạt động và dữ liệu lịch sử. Đồng thời, dữ liệu SSD sử dụng cấu trúc cây MemIAVL, trong khi dữ liệu bộ nhớ sử dụng cây IAVL (do Cronos phát minh) cho cam kết trạng thái, cung cấp gốc trạng thái để chạy sự đồng thuận. Ý tưởng trừu tượng của MemIAVL là mỗi khi một khối mới được cam kết, chúng tôi sẽ lấy tập hợp tất cả các thay đổi từ các giao dịch của khối đó và áp dụng những thay đổi đó cho cây IAVL trong bộ nhớ hiện tại, từ đó tạo ra một phiên bản mới của cây đối với khối mới nhất, để chúng ta có thể lấy được hàm băm gốc Merkle của cam kết khối. Do đó, nó tương đương với việc sử dụng bộ nhớ để cập nhật nóng, cho phép hầu hết quyền truy cập trạng thái được đặt trong bộ nhớ thay vì SSD, từ đó cải thiện IOPS.
Vấn đề chính của SeiDB là nếu dữ liệu hoạt động mới nhất được lưu trữ trong bộ nhớ, dữ liệu sẽ bị mất trong thời gian ngừng hoạt động, vì vậy MemIAVL giới thiệu các tệp WAL và ảnh chụp nhanh cây. Trong một khoảng thời gian nhất định, cần phải chụp nhanh dữ liệu trong bộ nhớ và lưu trữ trên đĩa cứng cục bộ. Kiểm soát khoảng thời gian chụp nhanh theo thời gian nhất định để kiểm soát kịp thời tác động OOM của việc mở rộng dữ liệu lên bộ nhớ.
so sánh cạnh nhau
Yêu cầu nút đầy đủ
Yêu cầu để chạy một nút đầy đủ
FireDancer có yêu cầu vận hành cao nhất đối với các nút và có thể được gọi là quái vật hiệu suất. Các yêu cầu về hiệu suất chính của MegaETH tập trung vào yêu cầu Sequencer của hơn 100 lõi. Do sự tồn tại của trình sắp xếp nút tập trung nên yêu cầu đối với các nút đầy đủ khác không cao. Hiện nay giá SSD tương đối thấp nên nhìn chung chúng ta chỉ nhìn vào yêu cầu hiệu năng của CPU và Memory. Chúng tôi xếp hạng các yêu cầu về hiệu suất của Full Node từ cao đến thấp: Firedancer > Sei > Monad > Sui > Aptos > MegaETH > Ethereum.
kế hoạch
Nói chung, đối với các giải pháp xử lý song song hiện tại, việc tối ưu hóa của chúng tôi ở cấp độ phần mềm chủ yếu tập trung vào 1. Các vấn đề về sử dụng IOPS của cơ sở dữ liệu, 2. Các vấn đề về nhận dạng trạng thái và 3. Các vấn đề về đường ống không đồng bộ được sử dụng để tối ưu hóa cấp độ phần mềm. Sự công nhận của trạng thái hiện được chia thành hai phe, đó là thực thi song song lạc quan và lập trình khai báo. Cả hai đều có ưu điểm và nhược điểm. Trong số đó, việc thực thi song song lạc quan chủ yếu dựa trên giải pháp Block-STM của Aptos. Các ứng dụng c chính của nó bao gồm Monad và Sei V2, trong khi Sui, Solana và Sei V1 đều là lập trình khai báo. Tương tự như mô hình lập trình đồng thời hoặc không đồng bộ truyền thống. Liên quan đến vấn đề tiêu thụ IPO của cơ sở dữ liệu, mỗi công ty có các giải pháp khác nhau:
So sánh kế hoạch
Về cấu trúc dữ liệu, chúng ta thấy một điểm khá thú vị là Monad được đặt trên SSD nhiều nhất có thể nhưng tốc độ đọc của ổ cứng lại thấp hơn Memory rất nhiều nhưng giá lại rẻ hơn rất nhiều. Monad được đặt trên SSD có tính đến giá cả, ngưỡng phần cứng và mức độ song song, vì hiện tại SSD có thể hỗ trợ 32 kênh hoạt động I/O để tăng thêm khả năng song song. Ngược lại, Solana và Sei chọn ánh xạ bộ nhớ vì bộ nhớ nhanh hơn SSD rất nhiều. Một là mở rộng các kênh song song theo chiều ngang và hai là mở rộng theo chiều dọc để giảm mức tiêu thụ I/O. Đây là lý do tại sao yêu cầu nút cho Monad là 32 GB, nhưng Sei và Solana lại yêu cầu nhiều bộ nhớ hơn.
Ngoài ra, cấu trúc dữ liệu của Ethereum bắt nguồn từ Cây Patric Merkel được phát triển từ Cây Patrci, do đó chuỗi công khai tương thích EVM cần phải tương thích với Merkel Trie nên không thể xây dựng những cách trừu tượng để suy nghĩ về các tài sản như Aptos, Sui, Solana, v.v. Ethereum dựa trên mô hình tài khoản, nhưng Sui là mô hình Đối tượng, Solana là mô hình tài khoản phân tách dữ liệu và mã và Ethereum thực sự được kết hợp với nhau.
Sự đổi mới mang tính đột phá xuất phát từ sự không khoan nhượng trong quá khứ. Từ góc độ kinh doanh, thực sự cần phải xem xét cộng đồng nhà phát triển và khả năng tương thích trong quá khứ của EVM có những ưu và nhược điểm.
Triển vọng
Các thành phần tối ưu hóa chính của việc thực thi song song hiện tại có mục tiêu tương đối rõ ràng, chủ yếu tập trung vào cách xác định trạng thái và cách cải thiện tốc độ đọc và lưu trữ dữ liệu, bởi vì cách lưu trữ những dữ liệu này sẽ khiến mất thêm thời gian để đọc hoặc lưu trữ một phần dữ liệu. dữ liệu. Chi phí chung và mức tiêu thụ, đặc biệt là Merkel thử giới thiệu xác minh gốc, nhưng nó mang lại chi phí IO siêu cao.
Mặc dù việc thực thi song song đã mở rộng chuỗi khối theo cấp số nhân nhưng nó vẫn có những điểm nghẽn cổ chai này vốn có trong các hệ thống phân tán, bao gồm mạng P2P, cơ sở dữ liệu và các vấn đề khác. Điện toán chuỗi khối vẫn còn một chặng đường dài trước khi có thể đạt được sức mạnh tính toán của máy tính truyền thống. Hiện tại, bản thân việc thực thi song song cũng phải đối mặt với một số vấn đề, bao gồm yêu cầu phần cứng ngày càng cao để thực thi song song, rủi ro về tập trung và kiểm duyệt do các nút ngày càng chuyên biệt mang lại và thiết kế cơ chế dựa trên bộ nhớ, các cụm hoặc nút trung tâm cũng sẽ Mang đến nguy cơ ngừng hoạt động, đồng thời, giao tiếp xuyên chuỗi giữa các chuỗi khối song song cũng sẽ là một vấn đề.
Mặc dù vẫn còn một số vấn đề nhất định với việc thực thi song song, mỗi công ty đang khám phá các phương pháp kỹ thuật tốt nhất, bao gồm kiến trúc thiết kế mô-đun do MegaETH dẫn đầu và kiến trúc thiết kế chuỗi nguyên khối do Monad dẫn đầu. Sơ đồ tối ưu hóa thực thi song song hiện tại thực sự chứng minh rằng công nghệ blockchain không ngừng tiến gần hơn đến sơ đồ tối ưu hóa máy tính truyền thống và ngày càng được tối ưu hóa ở cấp độ thấp nhất, đặc biệt là tối ưu hóa chi tiết về lưu trữ dữ liệu, phần cứng, đường ống và các công nghệ khác. Tuy nhiên, câu này vẫn còn những điểm nghẽn, vướng mắc nên vẫn còn một không gian rất rộng để các doanh nhân khám phá.
Sự đổi mới mang tính đột phá xuất phát từ việc không thỏa hiệp với quá khứ và chúng ta nóng lòng muốn thấy thêm nhiều doanh nhân không sẵn sàng thỏa hiệp để xây dựng những sản phẩm mạnh mẽ và thú vị hơn.
Tuyên bố từ chối trách nhiệm:
Nội dung trên chỉ mang tính tham khảo và không nên coi là bất kỳ lời khuyên nào. Luôn tìm kiếm lời khuyên chuyên nghiệp trước khi đầu tư.
Giới thiệu về Gate Ventures
Gate Ventures là nhánh đầu tư mạo hiểm của Gate.io, tập trung đầu tư vào cơ sở hạ tầng phi tập trung, hệ sinh thái và ứng dụng sẽ định hình lại thế giới trong kỷ nguyên Web 3.0. Gate Ventures làm việc với các nhà lãnh đạo ngành toàn cầu để trao quyền cho các nhóm và công ty khởi nghiệp có tư duy và năng lực đổi mới nhằm xác định lại mô hình tương tác của xã hội và tài chính.
Trang web chính thức: https://ventures.gate.io/ Twitter: https://x.com/gate_ventures Medium: https://medium.com/gate_ventures
