Tóm tắt: Bài nghiên cứu này cung cấp một cái nhìn tổng quan về các kiến trúc thiết kế song song cho blockchain, sử dụng ba ví dụ có liên quan: Solana, Sei và Monad. Nó nêu bật sự khác biệt giữa song song lạc quan và xác định và xem xét sự tinh tế trong trạng thái và truy cập bộ nhớ trên các chuỗi này.

Giới thiệu

Năm 1837, nhà khoa học máy tính và toán học Charles Babbage thiết kế “Máy Phân Tích,” mà đã đặt nền tảng lý thuyết cho tính toán song song. Ngày nay, song song hóa là một chủ đề then chốt trong thế giới tiền điện tử khi các blockchain cố gắng đẩy ranh giới của xử lý, hiệu suất và lưu lượng.

Vũ trụ song song

Tính toán song song cho phép nhiều phép tính hoặc quy trình được thực hiện đồng thời, so với việc tính toán thực hiện theo thứ tự hoặc một sau một. Tính toán song song đề cập đến việc chia nhỏ các vấn đề lớn thành các phần nhỏ, độc lập có thể được thực hiện bởi nhiều bộ xử lý giao tiếp thông qua bộ nhớ chia sẻ. Hệ thống song song có một số lợi ích, chẳng hạn như tăng hiệu suất và tốc độ, khả năng mở rộng, cải thiện độ tin cậy và khả năng chịu lỗi, tận dụng tài nguyên tốt hơn, và khả năng xử lý các bộ dữ liệu rất lớn.

Tuy nhiên, rất quan trọng nhận ra rằng hiệu suất của việc song song hóa phụ thuộc vào các chi tiết của kiến trúc và cài đặt cơ sở. Hai rào cản cốt lõi đối với các blockchain là các chức năng mật mã (hàm băm, chữ ký, các đường cong elliptical, v.v.) và truy cập bộ nhớ/trạng thái. Với các blockchain, một trong những thành phần chính của việc thiết kế một hệ thống song song hiệu quả nằm ở sự tinh tế trong việc truy cập trạng thái. Truy cập trạng thái đề cập đến khả năng của một giao dịch để đọc và ghi vào trạng thái của một blockchain, bao gồm lưu trữ, hợp đồng thông minh và số dư tài khoản. Để một blockchain song song hóa hiệu quả và hiệu suất, việc truy cập trạng thái phải được tối ưu hóa.

Hiện tại có hai trường phái về việc tối ưu hóa truy cập trạng thái cho blockchain song song: song song xác định so với song song lạc quan. Song song xác định yêu cầu mã để rõ ràng công bố trước đó các phần của trạng thái blockchain sẽ được truy cập và sửa đổi. Điều này cho phép hệ thống xác định được giao dịch nào có thể được xử lý song song mà không xung đột trước. Song song xác định cho phép dự đoán và hiệu quả (đặc biệt khi giao dịch hầu hết độc lập). Tuy nhiên, nó tạo ra sự phức tạp hơn cho các nhà phát triển.

Tối ưu hóa song song lạc quan không yêu cầu mã để khai báo quyền truy cập trạng thái của nó trước và xử lý các giao dịch theo cách song song như không có xung đột. Nếu xảy ra xung đột, tối ưu hóa song song sẽ hoặc chạy lại, xử lý lại, hoặc chạy các giao dịch xung đột theo thứ tự. Mặc dù tối ưu hóa song song cho phép nhiều linh hoạt cho các nhà phát triển, việc thực thi lại là cần thiết cho các xung đột, dẫn đến phương pháp này hiệu quả nhất khi các giao dịch không xung đột. Không có câu trả lời đúng đắn về việc phương pháp nào tốt hơn. Chúng đơn thuần chỉ là hai phương pháp khác nhau (và khả thi) cho việc song song hóa.

Trong Phần I của loạt bài này, chúng tôi sẽ trước tiên khám phá một số cơ bản về hệ thống song song không liên quan đến tiền điện tử, tiếp theo là không gian thiết kế cho việc thực thi song song cho chuỗi khối, tập trung vào ba lĩnh vực cốt lõi:

1. Tổng quan về Hệ thống Song Song Tiền Điện Tử
2. Phương pháp truy cập Bộ nhớ & Trạng thái
3. Cơ hội Thiết kế Song song

Hệ Thống Song Song Không Phải Tiền Điện Tử

Dựa vào những gì chúng ta vừa đọc ở trên về những gì tính toán song song cho phép và những lợi ích của các hệ thống song song, dễ hiểu tại sao việc áp dụng tính toán song song đã tăng vọt trong những năm gần đây. Việc áp dụng tính toán song song ngày càng gia tăng đã tạo điều kiện cho nhiều bước đột phá chỉ trong vài thập kỷ qua.

1. Hình ảnh y học: Xử lý song song đã biến đổi mạnh mẽ lĩnh vực hình ảnh y học, dẫn đến sự tăng đáng kể về tốc độ và độ phân giải trên nhiều phương pháp như MRI, CT, X-quang và tomography quang học. Nvidia đang ở vị trí hàng đầu trong những tiến bộ này, cung cấp cho các bác sĩ chuyên khoa hình ảnh khả năng trí tuệ nhân tạo cải tiến thông qua bộ công cụ xử lý song song của mình, giúp các hệ thống hình ảnh xử lý dữ liệu tăng và tải trọng tính toán một cách hiệu quả hơn.
2. Thiên văn học: Một số hiện tượng mới, như hiểu biết về lỗ đen, chỉ có thể được thực hiện thông qua việc sử dụng siêu máy tính song song.
3. Bộ máy trò chơi của Unity: Bộ máy của Unity sử dụng khả năng của GPU - được xây dựng cho các tải trọng đồ họa lớn - để giúp cải thiện hiệu suất và tốc độ. Bộ máy này được trang bị các tính năng xử lý đa luồng và song song, tạo ra trải nghiệm chơi game mượt mà và tạo ra môi trường chơi game phức tạp, chi tiết.

Hãy xem xét ba blockchain đã triển khai môi trường thực thi song song. Đầu tiên, chúng ta sẽ giải mã Solana, tiếp theo là hai chuỗi dựa trên EVM, Monad và Sei.

Tổng quan về Thiết kế Song song - Solana

Ở mức cao, triết lý thiết kế của Solana là sự tiến bộ của đổi mới blockchain phải tiến triển cùng với sự tiến bộ của phần cứng. Khi phần cứng cải thiện theo thời gian thông qua Định luật Moore, Solana được thiết kế để hưởng lợi từ hiệu suất và khả năng mở rộng tăng lên.Anatoly Yakovenkoban đầu thiết kếKiến trúc song song của Solanahơn năm năm trước, và ngày nay, sự song song như một nguyên tắc thiết kế khối đang lan rộng nhanh chóng.

Solana sử dụng song song xác định, đến từ kinh nghiệm trước đó của Anatoly làm việc với các hệ thống nhúng, nơi bạn thường khai báo tất cả trạng thái trước. Điều này cho phép CPU biết tất cả các phụ thuộc, từ đó cho phép nó để trước đối với các phần cần thiết của bộ nhớ. Kết quả là 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 làm việc thêm vào từ đầu. Trên Solana, tất cả các phụ thuộc bộ nhớ cho một chương trình được yêu cầu và được nêu trong giao dịch được xây dựng (tức là, Danh sách Truy cập), cho phép thời gian chạy để lên lịch và thực thi nhiều giao dịch song song một cách hiệu quả.

Thành phần chính tiếp theo trong kiến trúc của Solana là Sealevel VM, đây là thời gian chạy hợp đồng thông minh song song của Solana. Sealevel tự nhiên hỗ trợ xử lý song song nhiều hợp đồng và giao dịch dựa trên số lượng lõi mà trình xác thực có. Trình xác thực trong blockchain là người tham gia mạng chịu trách nhiệm xác minh và xác thực các giao dịch, đề xuất các khối mới và duy trì tính toàn vẹn và bảo mật của blockchain. Vì các giao dịch khai báo những tài khoản nào cần được đọc và ghi bị khóa trả trước, bộ lập lịch Solana có thể xác định giao dịch nào có thể được thực hiện đồng thời. Do đó, khi nói đến xác thực, "Nhà sản xuất khối" hoặc Đơn vị chỉ huy có thể sắp xếp hàng nghìn giao dịch đang chờ xử lý và lên lịch song song cho các giao dịch không chồng chéo.

Yếu tố thiết kế cuối cùng cho Solana là “pipelining.” Pipelining xảy ra khi dữ liệu cần được xử lý theo một loạt bước, và phần cứng khác nhau chịu trách nhiệm cho mỗi bước. Ý tưởng chính ở đây là lấy dữ liệu cần chạy tuần tự và song song hóa nó bằng cách sử dụng pipelining. Những đường ống này có thể chạy song song, và mỗi giai đoạn đường ống có thể xử lý các lô giao dịch khác nhau.

Những tối ưu hóa này cho phép Sealevel tổ chức và thực hiện các giao dịch độc lập đồng thời, tận dụng khả năng phần cứng để xử lý nhiều điểm dữ liệu cùng một lúc với một chương trình duy nhất. Sealevel sắp xếp các hướng dẫn theo programID và thực hiện cùng một hướng dẫn trên tất cả các tài khoản liên quan song song.

Với những đổi mới này trong tâm trí, chúng ta có thể thấy rằng Solana được thiết kế một cách có chủ ý để hỗ trợ song song hóa.

Tổng quan thiết kế song song - Sei

Sei là một blockchain Layer 1 mã nguồn mở, đa dụng được tinh chỉnh cho việc trao đổi tài sản kỹ thuật số. Sei V2 tận dụng song song lạc quan và do đó, thân thiện với các nhà phát triển hơn so với phiên bản quyết định của nó. Trong song song lạc quan, hợp đồng thông minh có thể được thực thi một cách mượt mà và đồng thời mà không cần các nhà phát triển khai báo tài nguyên của họ từ trước. Điều này có nghĩa là chuỗi chạy mọi giao dịch một cách lạc quan song song. Tuy nhiên, khi có xung đột (tức là, nhiều giao dịch truy cập vào cùng một trạng thái), blockchain sẽ theo dõi thành phần lưu trữ cụ thể mà mỗi giao dịch xung đột ảnh hưởng.

Các phương pháp blockchain của Sei thực hiện giao dịch bằng cách sử dụng “Kiểm soát đồng thời lạc quan (OCC).” Xử lý giao dịch đồng thời xảy ra khi nhiều giao dịch đồng thời tồn tại trong hệ thống. Có hai giai đoạn trong phương pháp giao dịch này: thực thi và xác nhận.

Trong giai đoạn thực thi, các giao dịch được xử lý một cách lạc quan, với tất cả các lần đọc/viết được lưu trữ tạm thời trong một cửa hàng cụ thể cho từng giao dịch. Sau đó, mỗi giao dịch sẽ bước vào giai đoạn xác nhận, trong đó thông tin về các hoạt động trong cửa hàng tạm thời được kiểm tra so với bất kỳ thay đổi trạng thái nào do các giao dịch trước đó thực hiện. Nếu một giao dịch độc lập, giao dịch sẽ chạy song song. Nếu một giao dịch đọc dữ liệu được sửa đổi bởi một giao dịch khác, điều này sẽ tạo ra một xung đột. Hệ thống song song của Sei sẽ xác định mỗi xung đột bằng cách so sánh tập hợp đọc của các giao dịch so với các thay đổi trạng thái mới nhất trong một cửa hàng đa phiên bản (được lập chỉ mục theo thứ tự giao dịch). Sei sẽ thực hiện lại và xác nhận lại các trường hợp xung đột phát sinh. Đây là một quá trình lặp lại liên quan đến việc thực thi, xác nhận, và chạy lại để sửa các xung đột. Đồ thị dưới đây minh họa cách tiếp cận của Sei đối với các giao dịch khi xảy ra xung đột.

Nguồn: https://blog.sei.io/sei-v2-the-first-parallelized-evm/

Việc triển khai của Sei dẫn đến việc giảm phí gas và mở rộng không gian thiết kế cho các nhà phát triển EVM. Lịch sử cho thấy, môi trường EVM đã bị hạn chế dưới 50 TPS, điều này buộc các nhà phát triển phải tạo ra các ứng dụng tuân thủ các mẫu ngược. Sei V2 cho phép các nhà phát triển tiếp cận các lĩnh vực mà thông thường yêu cầu hiệu suất cao và phí thấp, như DeFi, DePIN và Gaming.

Tổng quan về Thiết kế Song song - Monad

Monad đang xây dựng một lớp EVM song song Layer 1 với sự tương thích đầy đủ với bytecode. Điều làm cho Monad đặc biệt không chỉ là bộ máy song song của nó mà còn là những gì họ đã xây dựng dưới mái nhà để tối ưu hóa nó. Monad tiếp cận độc đáo với thiết kế tổng thể của mình bằng cách kết hợp một số tính năng quan trọng, bao gồm pipelining, I/O bất đồng bộ, tách biệt giữa sự đồng thuận và thực thi, và MonadDB.

Một đổi mới chính trong thiết kế của Monad là pipeliningvới một sự lệch nhẹ. Sự lệch cho phép nhiều quá trình được song song hóa bằng cách chạy nhiều phiên bản cùng một lúc. Do đó, việc xây dựng đường ống được sử dụng để tối ưu hóa một số chức năng, như xây dựng đường ống truy cập trạng thái, xây dựng đường ống thực thi giao dịch, xây dựng đường ống trong sự thống nhất và thực thi, và xây dựng đường ống trong cơ chế thống nhất chính.

Tiếp theo, chúng ta sẽ nhấp đúp vào phần song song của Monad. Trong Monad, các giao dịch được sắp xếp tuyến tính trong khối, nhưng mục tiêu là đạt đến trạng thái kết thúc này nhanh hơn bằng cách tận dụng thực thi song song. Monad sử dụng một thuật toán song song lạc quan cho thiết kế công cụ thực thi của nó. Công cụ của Monad xử lý các giao dịch đồng thời và sau đó thực hiện phân tích để đảm bảo rằng kết quả sẽ giống hệt nhau nếu các giao dịch được thực hiện lần lượt. Nếu có bất kỳ xung đột nào, bạn cần phải thực hiện lại. Việc thực hiện song song ở đây là một thuật toán tương đối đơn giản, nhưng kết hợp nó với những cải tiến quan trọng khác của Monad là điều làm cho cách tiếp cận này trở nên mới lạ. Một điều cần lưu ý ở đây là ngay cả khi thực thi lại xảy ra, nó thường rẻ vì các đầu vào cần thiết cho một giao dịch không hợp lệ hầu như sẽ luôn nằm trong bộ nhớ cache, vì vậy nó sẽ là một tra cứu bộ nhớ cache đơn giản. Thực hiện lại được đảm bảo thành công vì bạn đã thực hiện các giao dịch trước đó trong khối.

Monad cũng cải thiện hiệu suất bằng cách phân tách thực thi và đồng thuận, tương tự như Solana và Sei, ngoài việc thực thi bị trì hoãn. Ý tưởng ở đây là nếu bạn nới lỏng điều kiện để thực thi hoàn thành trước khi đồng thuận hoàn tất, bạn có thể chạy cả hai song song, dẫn đến thêm thời gian cho cả hai. Tất nhiên, Monad sử dụng một thuật toán xác định để xử lý điều kiện này để đảm bảo rằng một trong số chúng không chạy quá xa mà không thể đuổi kịp.

Phương pháp độc đáo để truy cập trạng thái & bộ nhớ

Như tôi đã đề cập ở đầu bài viết này, việc truy cập trạng thái là một trong những chướng ngại về hiệu suất điển hình đối với các chuỗi khối. Những lựa chọn thiết kế xung quanh việc truy cập trạng thái và bộ nhớ cuối cùng có thể quyết định liệu một cài đặt cụ thể của một hệ thống song song có cải thiện hiệu suất trong thực tế hay không. Ở đây, chúng tôi sẽ giải mã và so sánh các phương pháp khác nhau được áp dụng bởi Solana, Sei và Monad.

Truy cập trạng thái Solana: AccountsDB / Cloudbreak

Solana sử dụng việc mở rộng theo chiều ngang để phân phối và quản lý dữ liệu trạng thái trên nhiều thiết bị SSD. Nhiều chuỗi khối hiện nay sử dụng cơ sở dữ liệu thông thường (ví dụ, LevelDB) với hạn chế về xử lý một số lượng lớn các truy vấn đọc và ghi cùng lúc của dữ liệu trạng thái. Để tránh điều này, Solana đã 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 Cloudbreak.

Cloudbreak được thiết kế để truy cập song song qua các hoạt động I/O thay vì chỉ dựa vào RAM, mà theo bản chất là nhanh. Các hoạt động I/O (Input/Output) đề cập đến việc đọc dữ liệu từ hoặc ghi dữ liệu vào nguồn bên ngoài, như đĩa, mạng hoặc thiết bị ngoại vi. Ban đầu, Cloudbreak sử dụng một chỉ mục in-RAM để ánh xạ các khóa công khai với tài khoản giữ số dư và dữ liệu. Tuy nhiên, đến thời điểm viết bài và phiên bản 1.9, chỉ mục đã được chuyển từ RAM sang SSD. Sự chuyển đổi này cho phép Cloudbreak xử lý đồng thời 32 hoạt động I/O trong hàng đợi của mình, tăng hiệu suất qua nhiều ổ SSD. Do đó, dữ liệu blockchain như tài khoản và giao dịch có thể được truy cập một cách hiệu quả, như thể chúng đang ở trong RAM bằng cách sử dụng các tệp được ánh xạ bộ nhớ. Đồ thị dưới đây đại diện cho một cấu trúc bộ nhớ mẫu. Mặc dù RAM nhanh hơn, nhưng dung lượng ít hơn SSD và thường đắt đỏ hơn:

Biểu đồ phân cấp bộ nhớ minh họa

Bằng cách mở rộng theo chiều ngang và phân phối dữ liệu trạng thái trên nhiều thiết bị, Cloudbreak giảm độ trễ và cải thiện hiệu suất, phân quyền, và sự kháng cự mạng trong hệ sinh thái Solana.

Truy cập Sei State: SeiDB

Sei đã thiết kế lại lưu trữ của mình, SeiDB, để giải quyết một số vấn đề: tăng cường viết (cần bao nhiêu siêu dữ liệu để duy trì cấu trúc dữ liệu, càng nhỏ càng tốt), phình to, thao tác chậm, và suy giảm hiệu suất theo thời gian. Thiết kế mới bây giờ đã được chia thành hai thành phần: lưu trữ trạng thái và cam kết trạng thái. Ghi và xác minh bất kỳ thay đổi nào đối với dữ liệu đều được xử lý bởi cam kết trạng thái, trong khi cơ sở dữ liệu giữ tài khoản của tất cả dữ liệu tại bất kỳ thời điểm nào đều được xử lý bởi lưu trữ trạng thái (SS).

Trong Sei V2, Cam kết trạng thái sử dụng bộ nhớ được ánh xạKiến trúc cây IAVL (MemIAVL). Cây IAVL được ánh xạ bộ nhớ lưu trữ ít dữ liệu siêu dữ liệu hơn, giảm thời gian lưu trữ trạng thái và đồng bộ trạng thái và làm cho việc chạy một nút đầy đủ dễ dàng hơn nhiều. Cây IAVL được ánh xạ bộ nhớ được biểu diễn dưới dạng ba tập tin trên đĩa (kv, nhánh, lá); do đó, cần theo dõi ít dữ liệu siêu dữ liệu hơn, giúp giảm lưu trữ trạng thái lên tới 50%. Cấu trúc MemIAVL mới giúp giảm hệ số khuếch đại ghi vì nó giảm dữ liệu siêu dữ liệu cần thiết để duy trì cấu trúc dữ liệu.

SeiDB cập nhật cho phép hỗ trợ cơ sở dữ liệu linh hoạt cho lớp lưu trữ trạng thái. Sei tin rằng các nhà điều hành nút khác nhau sẽ có yêu cầu và nhu cầu lưu trữ đa dạng. Do đó, SS đã được thiết kế để chứa đựng các backend khác nhau, cung cấp cho các nhà điều hành sự tự do và linh hoạt, tức là PebbleDB, RocksDB, SQLite, v.v.

Truy cập trạng thái: MonadDB

Có một số sắc thái quan trọng khi truy cập trạng thái của Monad. Đầu tiên, hầu hết các máy khách Ethereum tận dụng hai loại cơ sở dữ liệu: cơ sở dữ liệu B-Tree (tức là LMDB) hoặc cơ sở dữ liệu log-structured merge tree (LSM) (tức là RocksDB, LevelDB). Cả hai đều là cấu trúc dữ liệu chung chung không được thiết kế một cách rõ ràng cho blockchain. Ngoài ra, cả hai cơ sở dữ liệu này đều không tận dụng những tiến bộ mới nhất trong công nghệ Linux, đặc biệt là về các hoạt động không đồng bộ và tối ưu hóa I/O. Cuối cùng, Ethereum chính nó quản lý trạng thái bằng cách sử dụngPatricia Merkle Trie, chuyên về mật mã, xác minh và chứng minh. Vấn đề chính là khách hàng phải tích hợp Trie Patricia Merkle cụ thể này vào cơ sở dữ liệu tổng quát hơn (ví dụ, B-Tree / LSM), với nhược điểm về hiệu suất đáng kể như việc truy cập đĩa quá mức.

Tất cả những điều trên giúp tạo nền tảng cho việc Monad quyết định tạo ra cơ sở dữ liệu MonadDB được xây dựng theo yêu cầu riêng của mình, được thiết kế đặc biệt để xử lý dữ liệu blockchain và truy cập trạng thái một cách hiệu quả hơn. Một số tính năng chính của MonadDB bao gồm một cơ sở dữ liệu truy cập song song, một cơ sở dữ liệu tùy chỉnh được tối ưu hóa cho Dữ liệu Merkle Trie, truy cập trạng thái hiệu quả hơn qua việc sử dụng RAM tiêu chuẩn, và sự phân cấp và khả năng mở rộng.

MonadDB được thiết kế một cách rõ ràng cho các khối khối, làm cho nó hiệu quả hơn khi sử dụng cơ sở dữ liệu thông thường. MonadDB tùy chỉnh được chuyên biệt và được tùy chỉnh để quản lý dữ liệu loại Merkle trie một cách hiệu quả, cho phép truy cập song song vào nhiều nút trie cùng một lúc. Mặc dù chi phí của việc đọc một lần trên MonadDB so với một số cơ sở dữ liệu thông thường được liệt kê ở trên là giống nhau, điểm quan trọng ở đây là MonadDB có thể chạy nhiều lần đọc song song, dẫn đến tốc độ nhanh chóng.

MonadDB cho phép truy cập trạng thái đồng thời vào cơ sở dữ liệu truy cập song song. Bởi vì Monad đang xây dựng cơ sở dữ liệu này từ đầu, nó có thể tận dụng các công nghệ nhân Linux mới nhất và toàn bộ sức mạnh của SSD cho I/O bất đồng bộ. Với async I/O, nếu một giao dịch yêu cầu đọc trạng thái từ đĩa, điều này không nên dừng lại để chờ hoàn tất. Thay vào đó, nó nên bắt đầu đọc và đồng thời tiếp tục xử lý các giao dịch khác. Đây là cách mà async I/O tăng đáng kể tốc độ xử lý cho MonadDB. Monad có thể đạt hiệu suất tốt hơn từ phần cứng bằng cách tối ưu hóa việc sử dụng SSD và giảm sự phụ thuộc vào RAM quá mức. Điều này còn có lợi ích bổ sung là phù hợp với sự phân quyền và khả năng mở rộng.

Tóm tắt so sánh cho Solana vs. Sei vs. Monad

Kết luận

Kết luận, việc khám phá song song trong blockchain thông qua góc nhìn của Solana, Sei và Monad cung cấp một hiểu biết toàn diện về cách kiến trúc và phương pháp khác nhau có thể cải thiện hiệu suất và khả năng mở rộng. Song song xác định của Solana, với sự nhấn mạnh vào việc khai báo truy cập trạng thái từ trước, mang lại sự dự đoán và hiệu quả, biến nó thành lựa chọn mạnh mẽ cho các ứng dụng yêu cầu lưu lượng cao. Ngược lại, phương pháp song song lạc quan của Sei ưu tiên tính linh hoạt của nhà phát triển và thích hợp cho môi trường mà xung đột giao dịch ít xảy ra. Với sự kết hợp độc đáo giữa song song lạc quan và MonadDB được xây dựng tùy chỉnh, Monad trình bày một giải pháp sáng tạo tận dụng các tiến bộ công nghệ mới nhất để tối ưu hóa truy cập trạng thái và hiệu suất.

Mỗi khối blockchain mang đến một cách tiếp cận riêng biệt để giải quyết các thách thức của việc song song hóa, với bộ thương mại riêng của mình. Thiết kế của Solana hướng đến việc tối đa hóa việc sử dụng phần cứng và thông lượng, trong khi Sei tập trung vào việc giảm bớt quá trình phát triển, và Monad nhấn mạnh vào giải pháp cơ sở dữ liệu tùy chỉnh cho dữ liệu blockchain. Những khác biệt này làm nổi bật sự đa dạng trong hệ sinh thái blockchain và sự quan trọng của việc chọn nền tảng phù hợp dựa trên nhu cầu cụ thể của ứng dụng.

Khi không gian Blockchain tiếp tục phát triển, những tiến bộ trong các kỹ thuật song song được thể hiện bởi Solana, Monad và Sei sẽ không nghi ngờ làm cho sự sáng tạo tiếp tục bay cao. Hành trình hướng tới các blockchain hiệu quả hơn, có khả năng mở rộng và thân thiện với các nhà phát triển đang diễn ra, và những bài học từ những nền tảng này sẽ đóng vai trò quan trọng trong việc định hình tương lai của công nghệ Blockchain.

Trong Phần II của loạt bài này, chúng tôi sẽ đào sâu vào các tác động kinh tế và sự đánh đổi liên quan đến các hệ thống thiết kế song song này.

免责声明：

1. Bài viết này được sao chép từ [khốiReciprocal Ventures], Tất cả bản quyền thuộc về tác giả gốc [Ali Sheikh]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Cổng Họcđội, và họ sẽ xử lý nó ngay lập tức.
2. Bảng từ chối 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 cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các 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 nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.