MỚI: Helius mua lại Light Protocol
Cách chuyển từ Ethereum sang Solana: Hướng dẫn cho nhà phát triển
Blog/Nghiên cứu

Cách chuyển từ Ethereum sang Solana: Hướng dẫn cho nhà phát triển

Developer Experience Engineer0xIchigo trên X0xIchigo trên LinkedIn0xIchigo trên GitHub
Đọc trong 41 phút
Mục lục

Bài viết này nói về điều gì?

Ethereum là một trong những đổi mới quan trọng nhất thời gian gần đây. Lần đầu tiên trong lịch sử, chúng ta có một nền tảng toàn cầu, phi tập trung được xây dựng để điều phối xã hội và có tiềm năng cách mạng hóa nhiều ngành. Dù rất quan trọng, môi trường runtime của Ethereum—Ethereum Virtual Machine (EVM)—ở trạng thái hiện tại chưa được xây dựng cho các ứng dụng hướng đến người tiêu dùng. Đây là một mạng đơn luồng, dựa trên gas với mức phí biến động. Ngược lại, Solana nổi lên như một mạng có thông lượng cao và độ trễ thấp. Mạng cung cấp hạ tầng xử lý song song với mức phí thấp, dễ dự đoán. Solana trực tiếp khắc phục các hạn chế của EVM và cải tiến thiết kế ban đầu, trở thành lựa chọn hấp dẫn cho các nhà phát triển muốn xây dựng ứng dụng có khả năng mở rộng và hiệu quả.

Bài viết này là hướng dẫn chuyển đổi toàn diện dành cho các nhà phát triển EVM muốn xây dựng trên Solana. Bài viết trình bày những khác biệt cơ bản giữa hai nền tảng, xem xét cơ chế đồng thuận, cách Ethereum và Solana xử lý giao dịch cũng như các ngôn ngữ dùng để phát triển hợp đồng thông minh. Tiếp theo là mô hình tài khoản của Solana, cung cấp cách tiếp cận đồng nhất và đa năng hơn đối với tài khoản. Bài viết cũng khám phá Solang và Neon EVM, hai công cụ thân thiện với Solidity giúp cải thiện trải nghiệm phát triển trên Solana.

Những khác biệt cơ bản

Phần này khám phá những khác biệt quan trọng giữa Ethereum và Solana, hai blockchain cùng hướng đến việc tạo ra một máy trạng thái phi tập trung để điều phối toàn cầu. Tuy nhiên, hai nền tảng khác nhau đáng kể về cơ chế đồng thuận, phương thức xử lý giao dịch và ngôn ngữ dùng để phát triển hợp đồng thông minh. Hiểu sâu hơn về những khác biệt cơ bản này sẽ làm rõ lợi thế riêng biệt của Solana so với Ethereum trong vai trò một máy trạng thái toàn cầu có hiệu năng cao.

Cơ chế đồng thuận

Cơ chế đồng thuận là nền tảng của mọi mạng blockchain. Chúng quyết định cách xác minh giao dịch và cách thêm khối vào blockchain một cách an toàn, hiệu quả và phi tập trung. Cả Ethereum và Solana đều là mạng Proof of Stake (PoS). Dù cùng dựa trên nền tảng PoS, cách hai mạng đạt đồng thuận khác nhau do các quy tắc xác nhận của chúng.

Ethereum sử dụng Gasper, một sự kết hợp giữa Casper the Friendly Finality Gadget (Casper-FFG) và thuật toán lựa chọn fork LMD-GHOST. Sự kết hợp này tạo thành cơ chế đồng thuận bảo vệ Ethereum.

Casper là một hệ thống finality dựa trên PoS, nâng trạng thái xác nhận của một khối lên “đã hoàn tất.” Một khối được coi là đã hoàn tất trên Ethereum khi hai phần ba tổng số stake bỏ phiếu ủng hộ việc đưa khối đó vào chuỗi và một khối khác được xây dựng trên nó. Vì finality yêu cầu hai phần ba tổng số stake đồng thuận rằng một khối thuộc chuỗi chính thức, kẻ tấn công không thể tạo ra một chuỗi đã hoàn tất thay thế nếu không sở hữu hoặc thao túng hai phần ba tổng số stake, đồng thời làm mất ít nhất một phần ba thông qua slashing. Casper cho phép người tham gia mới tự tin đồng bộ với chuỗi chính thức. 

LMD-GHOST là viết tắt của “Latest Message-Driven Greedy Heaviest Observed Sub-Tree.” Đây là thuật toán quyết định nên theo fork nào của Ethereum. Thuật toán chọn fork nhận được nhiều sự ủng hộ nhất (tức là có “trọng số” lớn nhất) từ các validator của mạng—do đó có cụm từ “greedy heaviest sub-tree.” Sau đó, nó đảm bảo chỉ xét thông điệp mới nhất từ mỗi validator. Mỗi khi một khối mới được đề xuất trên Ethereum, các validator dùng quy tắc này để quyết định khối đó có nên trở thành một phần của chuỗi chính thức hay không.

Trong khi đó, Solana sử dụng các hàm băm Proof of History (PoH) để đạt đồng thuận. Dù tên gọi dễ gây nhầm lẫn, PoH không phải là một thuật toán đồng thuận. Đây là cách chứng minh thời gian trong một mạng có đối thủ. Cụ thể hơn, nó là một hàm đóng dấu thời gian bằng mật mã, cho phép các node thống nhất về thứ tự sự kiện mà không cần giao tiếp với nhau. Leader (tức validator thêm các mục vào sổ cái) áp dụng dấu thời gian cho các khối để chứng minh một khoảng thời gian đã trôi qua kể từ khối trước. 

Việc thêm các dấu thời gian này tạo nên một bản ghi lịch sử vì chúng chứng minh dữ liệu đã tồn tại tại một thời điểm cụ thể. Bản ghi lịch sử được tạo bằng một hàm băm tuần tự kháng tiền ảnh, trong đó mỗi giá trị băm phụ thuộc vào giá trị trước đó. Các hàm trì hoãn có thể xác minh (VDF) đóng vai trò then chốt trong việc tạo ra các giá trị băm này. Chúng đảm bảo mỗi giá trị băm kế thừa giá trị trước và bao gồm khoảng thời gian đã trôi qua kể từ đó. Việc tích hợp VDF bổ sung yếu tố thời gian vào quá trình băm, cho phép tạo ra một chuỗi sự kiện có dấu thời gian và có thể xác minh trên Solana.

Sau khi hiểu cách cơ chế Proof of History của Solana tạo ra chuỗi sự kiện đáng tin cậy thông qua dấu thời gian mật mã, điều quan trọng là phải hiểu cách cơ chế này tích hợp với cơ chế đồng thuận Tower BFT của Solana. Tower Byzantine Fault Tolerance (BFT) là biến thể của Solana dựa trên mô hình đồng thuận Byzantine Fault Tolerance truyền thống, được tối ưu hóa cho PoH. Tower BFT sử dụng bản ghi lịch sử do PoH tạo ra làm khung tham chiếu. Khung này giúp các validator bỏ phiếu về trạng thái sổ cái một cách hiệu quả và chính xác. Tower BFT hoạt động bằng cách cho validator đưa ra các phiếu bầu bị khóa trong thời gian dài; mức độ cam kết tăng lên khi có thêm phiếu bầu. Nhờ PoH, validator có thể đưa ra quyết định nhanh hơn và đầy đủ thông tin hơn về trạng thái sổ cái mà không cần giao tiếp với nhau. Sự kết hợp giữa PoH và Tower BFT đẩy nhanh quá trình đồng thuận, đồng thời tăng cường tính bảo mật và độ tin cậy của mạng. Kết quả là một môi trường blockchain có thông lượng cao, có khả năng mở rộng và xác nhận giao dịch nhanh chóng.

Xử lý giao dịch và môi trường thực thi

Hiệu quả và khả năng mở rộng của blockchain chủ yếu được quyết định bởi năng lực xử lý giao dịch và môi trường thực thi. Những yếu tố này quyết định tốc độ thực thi giao dịch và hiệu quả chi phí của các hoạt động trên mạng. Cách blockchain xử lý giao dịch cùng những đặc điểm của môi trường thực thi ảnh hưởng đáng kể đến trải nghiệm của nhà phát triển.

Môi trường runtime của Ethereum hoạt động như một máy ngăn xếp đơn luồng, tất định, được gọi là Ethereum Virtual Machine (EVM). Nó hoạt động như một hàm toán học. Nghĩa là EVM tạo ra đầu ra tất định khi nhận một đầu vào. Có thể mô tả Ethereum bằng một hàm chuyển đổi trạng thái: f(S, T) = S’. Với trạng thái cũ (S) và một tập giao dịch hợp lệ mới (T), EVM tạo ra trạng thái đầu ra hợp lệ mới (S’). Khi nhận cùng một tập giao dịch, EVM luôn đạt đến cùng một trạng thái cuối. Điều này rất quan trọng để duy trì tính nhất quán giữa các node trong mạng.

EVM xử lý giao dịch tuần tự. Cách xử lý này đảm bảo mỗi giao dịch được thực thi trong một môi trường phản ánh chính xác trạng thái của mạng tại thời điểm đó. Thực thi tuần tự cho phép tính toán chính xác các thay đổi trạng thái và chi phí gas. Tính dễ dự đoán này giúp nhà phát triển và người dùng hiểu rõ kết quả cũng như chi phí giao dịch.

Ethereum đơn giản hóa môi trường thực thi hợp đồng thông minh bằng cách áp dụng mô hình thực thi đơn luồng. Điều này mang lại cho nhà phát triển lợi thế về khả năng dự đoán thay đổi trạng thái vì mỗi giao dịch được xử lý tuần tự. Những thay đổi trạng thái dễ dự đoán được cho là giúp môi trường phát triển của Ethereum dễ tiếp cận hơn với nhà phát triển mới, vì họ có thể tập trung vào logic hợp đồng thông minh thay vì sự phức tạp của quá trình thực thi. Tuy nhiên, sự đơn giản này khiến việc mở rộng trở nên khó khăn. Xử lý tuần tự giới hạn thông lượng mạng. Điều này có thể gây tắc nghẽn, kéo dài thời gian chờ giao dịch và làm tăng phí gas khi nhu cầu cao. Vì mọi giao dịch đều tiêu tốn gas, nhà phát triển buộc phải tối ưu hóa hiệu quả sử dụng gas. Việc tối ưu hóa giúp cải thiện trải nghiệm tổng thể của người dùng và hạn chế tác động của tình trạng tắc nghẽn, khi mã kém hiệu quả có thể khiến ứng dụng trở nên không thể sử dụng đối với người dùng thông thường.

Nhà phát triển Solana không phải lo lắng về việc tối ưu hóa mức sử dụng gas như nhà phát triển Ethereum. Solana được thiết kế như một máy trạng thái có thông lượng cao và độ trễ thấp, được gọi là Solana Virtual Machine (SVM). Một thành phần quan trọng của SVM là Sealevel. Đây là một công cụ runtime xử lý giao dịch song song. Trên Solana, mỗi giao dịch cho runtime biết nó sẽ đọc hoặc ghi những phần trạng thái nào khi được thực thi. Runtime xử lý song song các giao dịch không xung đột và các giao dịch đọc cùng một trạng thái. Sealevel tối ưu hóa việc thực thi hợp đồng thông minh bằng cách phân phối khối lượng công việc giao dịch trên nhiều luồng thuộc phần cứng của validator. Vì vậy, trong khi validator xử lý một giao dịch trên một lõi, một giao dịch khác có thể đồng thời được xử lý trên lõi khác.

Khả năng xử lý song song vốn có của Solana giúp giảm đáng kể chi phí giao dịch. Giao dịch Solana có hai loại phí: phí cơ sở và phí ưu tiên. Phí cơ sở được cố định ở mức 5000 lamport cho mỗi chữ ký; hầu hết giao dịch chỉ có một chữ ký. Phí ưu tiên là tùy chọn, cho phép giao dịch tự ưu tiên trước các giao dịch khác. Bộ lập lịch ưu tiên các giao dịch có phí ưu tiên cao hơn theo cách không tất định. Phí giao dịch thường thấp hơn 0,001 USD, trong đó phí trung bình của giao dịch không bỏ phiếu nằm trong khoảng 0,000005 đến 0,00007 SOL. Cận trên cao hơn bình thường do mức sử dụng phí ưu tiên gần đây tăng lên. Với giá SOL hiện tại là ~98,96 USD, mức phí này tương đương khoảng 0,000494 đến 0,006968 USD. 

Các khoản phí này cũng dễ dự đoán. Solana sử dụng thị trường phí cục bộ để quản lý nhu cầu. Không gian khối được cấu trúc nhằm ngăn một điểm nóng hoạt động riêng lẻ—chẳng hạn một đợt mint NFT đang gây sốt—chiếm lĩnh không gian khối và đẩy phí tăng trên toàn mạng. Chỉ những giao dịch cố truy cập một điểm nóng cụ thể có nhu cầu cao mới chịu mức phí tăng. Thị trường phí cục bộ cho phép sử dụng phí ưu tiên mà không dẫn đến cuộc chiến gas toàn diện. Tính cục bộ này khác với các mạng dựa trên gas như Ethereum, nơi giao dịch được xử lý tuần tự và tình trạng tắc nghẽn toàn mạng khiến phí biến động.

Ethereum là môi trường runtime đơn luồng, mỗi lần chỉ xử lý một hợp đồng. Hiện tại, nền tảng này không tận dụng phần cứng đa lõi hiện đại, khiến phần cứng của validator không được sử dụng hết công suất. Mong muốn duy trì yêu cầu phần cứng thấp cho các node càng làm tăng những hạn chế trong khả năng xử lý giao dịch của Ethereum. Trong khi đó, khả năng xử lý song song cho phép Solana xử lý nhiều giao dịch hơn bằng cách tận dụng tất cả các lõi hiện có của validator. Khi kết hợp với thị trường phí cục bộ, Solana trở thành một máy trạng thái toàn cầu có hiệu năng vượt trội hơn nhiều. 

Ngôn ngữ hợp đồng thông minh

Ngôn ngữ chính để phát triển hợp đồng thông minh trên Ethereum là Solidity. Đây là ngôn ngữ định kiểu tĩnh, sử dụng dấu ngoặc nhọn và được thiết kế để tạo các hợp đồng thông minh chạy trên EVM. Solidity chịu ảnh hưởng lớn từ JavaScript, C++ và Python, nên các nhà phát triển quen thuộc với những ngôn ngữ này có thể dễ dàng tiếp cận.

Yul là ngôn ngữ trung gian cấp thấp được tối ưu hóa cho các blockchain tương thích với EVM. Yul giúp nhà phát triển kiểm soát tốt hơn việc thực thi bytecode, đặc biệt hiệu quả khi tinh chỉnh mức tiêu thụ gas và quản lý các thao tác cấp thấp khác. Nhà phát triển có thể tạo hợp đồng hiệu quả hơn bằng cách viết mã trực tiếp bằng Yul hoặc dùng Yul làm đích biên dịch.

Vyper là một ngôn ngữ phổ biến mang phong cách Python, chú trọng tính đơn giản và bảo mật. Ngôn ngữ này chủ ý có ít tính năng hơn Solidity nhằm giảm độ phức tạp và các lỗ hổng bảo mật tiềm ẩn. Triết lý thiết kế của Vyper đặt khả năng đọc và kiểm tra lên hàng đầu. Cách tiếp cận này đã truyền cảm hứng cho việc phát triển các ngôn ngữ tương tự như Fe, cũng như các ngôn ngữ biên dịch sang Vyper như Dasy.

Rust là lingua franca để phát triển hợp đồng thông minh—thường được gọi là program—trên Solana. Đây là ngôn ngữ nhanh, sử dụng bộ nhớ hiệu quả và có hiệu năng tương đương C++. Những đặc điểm này giúp Rust phù hợp để phát triển ứng dụng cho một mạng có thông lượng cao và độ trễ thấp. Hệ thống kiểu phong phú và mô hình quyền sở hữu của Rust đảm bảo an toàn cho bộ nhớ và luồng, buộc nhà phát triển phải xây dựng các ứng dụng đáng tin cậy và an toàn. 

Dù Rust có lộ trình học khá khó đối với người mới làm quen với lập trình hệ thống, đổi lại, nhà phát triển có thể tạo ra mã mạnh mẽ và hiệu quả. Phần lớn hoạt động phát triển Rust được thực hiện bằng Anchor. Anchor là một framework có định hướng rõ ràng, giúp đơn giản hóa việc phát triển program bằng cách giảm mã mẫu, thực hiện nhiều bước kiểm tra bảo mật tiêu chuẩn và tinh giản quá trình tuần tự hóa/giải tuần tự hóa. Nhờ đó, kiến thức Rust nâng cao không còn quá quan trọng khi bắt đầu. Để tham khảo, tài liệu Anchor khuyến nghị người dùng nên nắm vững chín chương đầu tiên của Rust Book, tức là hiểu các kiến thức cơ bản về Rust. Solana Playground có nhiều hướng dẫn về Anchor để giúp bạn bắt đầu.

Dù Rust là lựa chọn ưu tiên, nhà phát triển không bị giới hạn ở ngôn ngữ này. Có thể sử dụng C, C++ và bất kỳ ngôn ngữ nào nhắm đến backend BPF của LLVM, tức bất kỳ ngôn ngữ nào có thể biên dịch thành BPF bytecode. Với những người quen thuộc với các ngôn ngữ mang phong cách Python như Vyper, Seahorse Lang cho phép viết program bằng Python. Nhà phát triển có được sự dễ dùng của Python trong khi vẫn duy trì các đảm bảo an toàn tương tự như khi viết mã bằng Rust. Nhiều tài liệu hướng dẫn hữu ích về Seahorse, chẳng hạn Seahorse University và Seahorse Cookbook, có thể giúp bạn bắt đầu lập trình trên Solana ngay hôm nay.

Các nhà phát triển chuyển từ Ethereum sang Rust không bị bó buộc vào Rust. Dù nên học và sử dụng các framework như Anchor và Seahorse nhờ mức độ phổ biến cùng các đảm bảo bảo mật của chúng, điều này không phải lúc nào cũng khả thi. Nhờ những bước phát triển gần đây của Solang và Neon Labs với trình biên dịch và môi trường phát triển tương thích EVM, nhà phát triển có thể dùng Solidity để phát triển program. Solidity đã có chỗ đứng trên Solana. Để bắt đầu phát triển program bằng Solidity, chúng ta cần tìm hiểu sâu hơn về các đặc điểm trong mô hình lập trình của Solana. Việc hiểu mô hình tài khoản của Solana rất quan trọng đối với các nhà phát triển thực hiện quá trình chuyển đổi này, vì đây là nền tảng để phát triển program và tương tác trên mạng.

Tìm hiểu mô hình tài khoản

Ethereum chia tài khoản thành hai loại chính: tài khoản thuộc sở hữu bên ngoài (EOA) và tài khoản hợp đồng. EOA là loại tài khoản tiêu chuẩn dành cho người dùng. Chúng được kiểm soát bằng khóa riêng và có thể nắm giữ số dư Ether, gửi giao dịch cũng như tương tác với tài khoản hợp đồng. Mặt khác, tài khoản hợp đồng khác biệt ở chỗ hoạt động của chúng được chi phối bởi mã hợp đồng thông minh nhúng bên trong. Chúng không thể tự khởi tạo giao dịch và chỉ có thể hành động để phản hồi giao dịch nhận được từ EOA hoặc các tài khoản hợp đồng khác.

Solana áp dụng mô hình tài khoản đồng nhất hơn, xem tài khoản như những vùng chứa đa chức năng lưu trữ dữ liệu lâu dài. Mô hình này cho phép bất kỳ tài khoản nào cũng có thể là một program, làm mờ ranh giới truyền thống giữa tài khoản và hợp đồng thông minh. Không giống Ethereum, nơi mã và trạng thái được kết hợp trong một tài khoản duy nhất, program trên Solana không có trạng thái. Điều này có nghĩa là chúng không lưu trữ trạng thái nội bộ. Thay vào đó, mọi dữ liệu cần thao tác đều được lưu trong một tài khoản riêng và được truyền bằng tham chiếu cùng với giao dịch. Việc truyền tài khoản bằng tham chiếu cho phép triển khai một program dùng chung có thể tương tác với nhiều tài khoản khác nhau. Mô hình tài khoản của Solana tách biệt mã và dữ liệu, tạo ra một môi trường phát triển hiệu quả và theo mô-đun hơn. Điều này có lợi cho người dùng muốn tương tác với nhiều giao thức mà không cần di chuyển tài sản giữa các program khác nhau. Mọi thứ trên Solana đều là tài khoản. 

Tài khoản Solana có thể được phân loại khái quát thành tài khoản thực thi được và không thực thi được. Nói đơn giản, tài khoản thực thi được là tài khoản có khả năng chạy mã. Tài khoản không thực thi được dùng để lưu trữ dữ liệu và không có khả năng chạy mã vì chúng không lưu trữ mã.

Tài khoản thực thi được là những tài khoản chứa program. Program có thể sở hữu các tài khoản bổ sung, đọc hoặc ghi có vào tài khoản khác, sửa đổi dữ liệu hay ghi nợ các tài khoản do chúng sở hữu. Tài khoản thực thi được có thể tiếp tục chia thành program on-chain hoặc program gốc. Program on-chain là mã do người dùng viết và triển khai lên mạng. Chúng có thể được nâng cấp bởi quyền nâng cấp, thường là tài khoản đã triển khai chúng. Program gốc là một tập con đặc biệt của các tài khoản thực thi được, tương tự hợp đồng biên dịch sẵn của Ethereum nhưng có chức năng rộng hơn. Các program này được tích hợp vào lõi của Solana, cung cấp những chức năng cần thiết để validator hoạt động. Một ví dụ về program gốc là System Program. Program này chịu trách nhiệm tạo tài khoản mới, phân bổ dữ liệu tài khoản, gán tài khoản cho program, chuyển lamport từ các tài khoản do nó sở hữu và thanh toán phí giao dịch. Bạn có thể xem danh sách đầy đủ các program gốc tại đây.

Bất kể có thực thi được hay không, mọi tài khoản đều có các trường giống nhau: 

  • Trường lamports để theo dõi số dư gốc bằng SOL của tài khoản
  • Trường data, chỉ mảng byte dữ liệu thô được tài khoản lưu trữ
  • Trường owner, cho biết program có thể sửa đổi tài khoản này
  • Trường signer, được dùng trong giao dịch để cho biết tài khoản có thể phê duyệt giao dịch hay không
  • Trường writable, xác định dữ liệu của tài khoản có thể được sửa đổi hay không. Trường này hỗ trợ xử lý song song bằng cách đánh dấu các tài khoản có trong giao dịch là chỉ đọc hoặc có thể ghi
  • Trường executable, cho biết tài khoản có lưu trữ program hay không
  • Trường rent epoch, cho biết epoch tiếp theo mà tài khoản phải trả phí thuê

Phí thuê là chi phí lưu trữ để duy trì tài khoản trên Solana và đảm bảo chúng được giữ trong bộ nhớ của validator. Điều này yêu cầu tài khoản duy trì số dư tối thiểu để tiếp tục hoạt động. Phí thuê giảm tình trạng phình to trạng thái bằng cách đảm bảo mạng cuối cùng sẽ thu hồi các tài khoản không được sử dụng hoặc không đủ tiền. Các bản cập nhật gần đây đã loại bỏ tài khoản phải trả phí thuê trên mainnet. Thay vào đó, mọi tài khoản phải được miễn phí thuê ngay khi tạo. Một tài khoản được miễn phí thuê nếu duy trì số dư tối thiểu tương đương hai năm tiền thuê. Có thể dùng các công cụ như Test Drive và lệnh con rent của Solana CLI để ước tính lượng SOL cần thiết nhằm giúp tài khoản được miễn phí thuê. Cách này khác với hệ thống phân bổ tài nguyên của Ethereum, nơi dữ liệu lưu trữ vẫn tồn tại trừ khi bị xóa rõ ràng. Cách tiếp cận của Solana cung cấp cấu trúc chi phí dễ dự đoán hơn cho việc lưu trữ trạng thái, đồng thời giảm tình trạng phình to trạng thái.

Địa chỉ và Program Derived Address (PDA)

Mọi tài khoản đều được nhận diện bằng địa chỉ của mình, một khóa công khai 32 byte duy nhất. Điều này khác với mô hình dữ liệu của Ethereum, nơi địa chỉ có độ dài 20 byte. Solana sử dụng ed25519—tức một lược đồ chữ ký EdDSA sử dụng SHA-512 và đường cong elliptic Curve22519—để tạo địa chỉ. Một tài khoản phải là một điểm trên đường cong ed25519 để có cặp khóa hợp lệ. 

Program Derived Address (PDA) là các tài khoản được tạo ngoài đường cong bằng một bump, tức giá trị đẩy đầu ra ra khỏi đường cong. PDA cần ba phần chính: địa chỉ của program mẹ, một tập seed và một bump. Các seed là một mảng chuỗi có thể mang giá trị tùy ý. Tuy nhiên, phần lớn nhà phát triển tạo các seed cụ thể liên quan đến biến trạng thái trong program mẹ để xây dựng cấu trúc dữ liệu tương tự hashmap. Vì vậy, PDA được tạo bằng cách băm program ID, các seed và bump bằng hàm băm SHA-512.

Mục đích của việc đặt PDA ngoài đường cong là để chỉ program mà PDA được dẫn xuất từ đó mới có thể ký thay cho PDA. Cách này hợp lý hóa luồng giao dịch bằng cách tạo chữ ký giao dịch theo chương trình, giúp các dApp không cần niềm tin có thể vận hành trơn tru mà không cần can thiệp.

Tương tác với tài khoản

Giao dịch Ethereum là một hành động thay đổi trạng thái do EOA khởi tạo. Hợp đồng thông minh không thể tự khởi tạo giao dịch; chúng chỉ có thể phản hồi giao dịch. Mã của hợp đồng quyết định những phản hồi này, còn chi phí thực thi giao dịch được đo bằng gas. Người dùng phải cung cấp đủ Ether để thanh toán phí gas này.

Giao dịch Ethereum thường thực hiện một thao tác duy nhất, chẳng hạn gọi một hàm cụ thể của hợp đồng thông minh. Dù một giao dịch có thể dẫn đến nhiều thay đổi trạng thái trong hợp đồng, mọi thay đổi đều bị giới hạn trong phạm vi của lần gọi hợp đồng đó.

Trên Solana, một giao dịch gồm một mảng tài khoản để đọc hoặc ghi, một hoặc nhiều chữ ký và một hoặc nhiều instruction. Instruction là chỉ thị cho một lần gọi program. Đây là đơn vị logic thực thi nhỏ nhất và là đơn vị vận hành cơ bản nhất. Instruction chỉ định program thực thi, tất cả tài khoản liên quan và dữ liệu thao tác. Program diễn giải dữ liệu từ instruction và thao tác trên các tài khoản được chỉ định. Cấu trúc này cho phép một giao dịch duy nhất thực hiện một chuỗi hành động trên nhiều program theo cách nguyên tử. Điều này có nghĩa là mọi instruction đều cùng thành công hoặc cùng thất bại. Luồng giao dịch của Solana khác với mô hình Ethereum, nơi một giao dịch thường được liên kết với một hợp đồng thông minh duy nhất hoặc một hành động của EOA.

Lệnh gọi chéo program (CPI) cho phép một program gọi program khác trong cùng một giao dịch. Số byte dữ liệu tài khoản trên mỗi đơn vị tính toán bị tính phí trong một CPI là 250. Con số này tương đương khoảng 50 MB ở mức 200.000 đơn vị. CPI cho phép sử dụng chữ ký được tạo theo chương trình khi gọi giữa các program. Điều này tương tự việc một hợp đồng thông minh Ethereum gọi một hợp đồng khác một cách hiệu quả và nguyên tử. Tuy nhiên, program gọi sẽ tạm dừng cho đến khi program được gọi xử lý xong instruction. Khả năng tái nhập bị giới hạn ở đệ quy trực tiếp vào chính nó với độ sâu cố định tối đa là 4. Điều này ngăn trường hợp một program gọi program khác từ trạng thái trung gian mà không biết rằng sau đó nó có thể bị gọi ngược lại.

Giao dịch Solana tuân theo giới hạn kích thước để đảm bảo hiệu quả, tương tự giới hạn gas của Ethereum. Tuy nhiên, trọng tâm ở đây là kích thước dữ liệu. Giao dịch Solana tuân theo tiêu chuẩn Đơn vị truyền tối đa (MTU) của IPv6 để đảm bảo truyền dữ liệu đáng tin cậy. Sau khi dành không gian cần thiết cho header, còn lại 1232 byte cho dữ liệu gói tin. Solana đã giới thiệu giao dịch có phiên bản để hỗ trợ nhiều định dạng giao dịch nhằm khắc phục giới hạn kích thước. Ngoài định dạng cũ, tức định dạng giao dịch ban đầu, Version 0 được phát hành để hỗ trợ Address Lookup Table (ALT). ALT lưu trữ địa chỉ trong cấu trúc dữ liệu dạng bảng on-chain, trong đó mỗi địa chỉ được lập chỉ mục bằng chỉ mục u8 dài 1 byte. Điều này làm giảm đáng kể kích thước giao dịch vì mỗi tài khoản chỉ cần 1 byte thay vì 32 byte.

Solang

Solang là trình biên dịch Solidity cho Solana và Polkadot. Công cụ này hướng đến khả năng tương thích ở cấp tệp nguồn với phiên bản 0.8 của trình biên dịch Solidity trên EVM, dù có một số điều chỉnh để phù hợp với kiến trúc của Solana và Polkadot. Một khía cạnh quan trọng của Solang là việc sử dụng LLVM, một hạ tầng trình biên dịch mạnh mẽ. Tính linh hoạt của LLVM cho phép Solang mở rộng hỗ trợ sang các ngôn ngữ lập trình khác trong tương lai, giúp việc triển khai và biên dịch dễ dàng hơn. Đặc điểm này phù hợp với mục tiêu của Solang là giúp các nhà phát triển chuyển sang Solana hoặc Polkadot dễ dàng hơn, đồng thời mở rộng phạm vi phát triển bằng Solidity. Solang được phát triển liên tục, tập trung cải thiện khả năng tương thích, hiệu quả và tính thân thiện với người dùng. Các nhà phát triển Ethereum muốn đưa kỹ năng của mình sang nhiều blockchain cần hiểu rõ Solang và những điểm cần lưu ý của công cụ này.

Cài đặt

Có một số cách để cài đặt Solang. Trên Mac, người dùng có thể tải Solang bằng Brew thông qua một tap riêng:

Mã
brew install hyperledger/solang/solang

Một cách khác để cài đặt Solang là dùng các container Solang. Cách này rất phù hợp nếu bạn thích dùng Docker, vì các image mới sẽ tự động được cung cấp trên những container này. Có một tag v.0.3.3 và một tag latest:

Mã
docker pull ghcr.io/hyperledger/solang:latest

Một trong những cách dễ hơn để cài đặt và sử dụng Solang là thông qua Ancor. Trước tiên, hãy đảm bảo Rust và Node.js đã được cài đặt trên hệ thống. Người dùng Windows cũng cần thiết lập Windows Subsystem for Linux. Tiếp theo, chúng ta cần cài đặt Bộ công cụ Solana. Trên Mac và Linux, có thể thực hiện bằng lệnh sau:

Mã
 sh -c "$(curl -sSfL https://release.solana.com/v1.17.13/install)"

Nếu muốn dùng phiên bản phần mềm khác, hãy thay “v1.17.13” bằng tag bản phát hành phù hợp. Ngoài ra, bạn có thể dùng một trong các tên kênh tượng trưng sau: stable, beta hoặc edge. Tùy thuộc vào hệ thống, bạn có thể cần cập nhật biến môi trường PATH. Nếu gặp thông báo này, hãy sao chép và dán lệnh được đề xuất bên dưới để cập nhật PATH. Bạn có thể xác nhận phiên bản solana mong muốn bằng cách chạy solana --version.

Trên Windows, hãy mở Command Prompt với quyền Quản trị viên. Sao chép và dán lệnh sau để tải trình cài đặt Solana vào một thư mục tạm thời:

Mã
cmd /c "curl https://release.solana.com/v1.17.13/solana-install-init-x86_64-pc-windows-msvc.exe --output C:\solana-install-tmp\solana-install-init.exe --create-dirs"

Sau đó, sao chép và dán lệnh sau để cài đặt phiên bản Solana mới nhất: C:\solana-install-tmp\solana-install-init.exe v1.17.13. Khi cài đặt hoàn tất, nhấn Enter.

Đóng cửa sổ Command Prompt rồi mở lại một cửa sổ mới với tư cách người dùng thông thường. Xác nhận phiên bản solana mong muốn đã được cài đặt bằng cách chạy solana –-version.

Tiếp theo, cài đặt Anchor.

Bạn nên cài đặt Anchor bằng trình quản lý phiên bản Anchor (avm). Có thể thực hiện qua cargo bằng lệnh:

Mã
cargo install -git https://github.com/coral-xyz/anchor avm --locked --force.

Sau đó, cài đặt và sử dụng phiên bản mới nhất:

Mã
avm install latest
avm use latest

# Verify the installation
avm –version

Anchor phiên bản 0.28 cho phép nhà phát triển build trực tiếp bằng Solang. Nhà phát triển có thể tạo một dự án Solang mới bằng lệnh: anchor init project_name —solidity. Lệnh này tạo một chương trình Solang mới và một tệp kiểm thử minh họa cách tương tác với chương trình thông qua client.

Nếu dùng Visual Studio Code, hãy cân nhắc cài đặt extension Solang để hỗ trợ tô sáng cú pháp. Tắt mọi extension Solidity khác đang hoạt động để đảm bảo extension Solang vận hành chính xác.

Tạo dự án mới

Tạo một dự án mới bằng lệnh anchor-init project_name –solidity. Lệnh này tạo một thư mục mới mang tên dự án. Cờ Solidity cho Anchor biết rằng chúng ta muốn dùng Solang. Thư mục ./solidity của dự án sẽ cung cấp một chương trình khởi đầu. Contract sẽ có dạng như sau:

Mã
@program_id("F1ipperKF9EfD821ZbbYjS319LXYiBmjhzkkf5a26rC")
contract test {
    bool private value = true;

    @payer(payer)
    constructor() {
        print("Hello, World!");
    }

    /// A message that can be called on instantiated contracts.
    /// This one flips the value of the stored `bool` from `true`
    /// to `false` and vice versa.
    function flip() public {
            value = !value;
    }

    /// Simply returns the current value of our `bool`.
    function get() public view returns (bool) {
            return value;
    }
}

Chương trình này có một constructor để tạo chương trình, khởi tạo biến trạng thái value thành true và ghi “Hello, World!” vào log của chương trình. Hàm flip cập nhật biến trạng thái khi được gọi. Hàm get trả về giá trị hiện tại của biến trạng thái. Contract này trông giống một smart contract Solidity thông thường, nhưng có một số điểm cần lưu ý. Khác biệt đáng kể nhất là việc sử dụng annotation.

Annotation

Annotation được dùng để quản lý account. Hãy chú ý đến annotation @program_id(“...”). Annotation này dùng để chỉ định địa chỉ on-chain của chương trình nếu địa chỉ đó đã được biết trước. Nếu muốn gọi một contract qua lệnh gọi bên ngoài, chương trình phải có ký hiệu @program_id hoặc được gọi bằng đối số {program_id: … }:

Mã
@program_id(“...”);

contract Foo {
	function hello() public pure {
		print(“Hello”);
	}
}

contract Foo2 {
	function bye() public pure {
		print(“Bye”);
	}
}

contract Bar {
	function new_foo() external {
		Foo.new();
	}
}

contract Bar2 {
	function new_foo(address new_foo_id) external {
		Foo2.new{program_id: new_foo_id}();
	}
}

Khi chúng ta tạo dự án mới, contract mẫu được cung cấp có annotation @payer phía trên constructor. Annotation này xác định account sẽ thanh toán chi phí khởi tạo data account của chương trình. Cú pháp @payer(payer) khai báo một account có tên payer, account này sẽ cần thiết cho mọi lệnh gọi đến constructor.

Khi một contract được khởi tạo, contract đó cần một program account để lưu mã thực thi và một data account để lưu các biến trạng thái. Data account có thể được tạo bằng mã phía client rồi truyền vào transaction gọi constructor. Hoặc constructor có thể tạo data account. Tối thiểu phải cung cấp annotation @payer. Nếu data account là PDA, phải cung cấp seed và bump. Annotation @seed chỉ định seed để dẫn xuất PDA và có thể là chuỗi ký tự hoặc chuỗi hex theo định dạng hex”1234”. Nếu nằm trước một đối số, annotation seed phải tham chiếu đến đối số thuộc kiểu bytes, address hoặc mảng byte có độ dài cố định. Annotation @bump chỉ định giá trị dùng để tạo địa chỉ nằm ngoài đường cong. Giá trị này phải là một byte duy nhất thuộc kiểu bytes1. Có thể dùng annotation tùy chọn @space để chỉ định kích thước của data account. Đây là một biểu thức uint64 có thể là hằng số hoặc sử dụng một trong các đối số của constructor. Theo tài liệu Solang, tối thiểu @space phải là kích thước được cung cấp khi chạy lệnh solang -v:

Mã
$ solang compile --target solana -v examples/solana/flipper.sol
...
info: contract flipper uses at least 17 bytes account data
…

Nếu một chương trình không có constructor, có thể ghép các annotation này với một constructor trống. Tài liệu Solang cung cấp ví dụ sau:

Mã
@program_id("Foo5mMfYo5RhRcWa4NZ2bwFn4Kdhe8rNK5jchxsKrivA")
contract Foo {

    @space(500 + 12)
    @seed("Foo")
    @payer(payer)
    constructor(@seed bytes seed_val, @bump bytes1 bump_val) {
        // ...
    }
}

Annotation hàm được dùng để khai báo các account cần thiết cho hàm bên ngoài:

  • @account(foo) khai báo account foo là account chỉ đọc
  • @mutableAccount(bar) khai báo account bar là account có thể thay đổi
  • @signer(fizz) khai báo account fizz là bên ký chỉ đọc
  • @mutableSigner(buzz) khai báo account buzz là bên ký có thể thay đổi

Có thể truy cập bên trong constructor các account được khai báo bằng annotation @payer trên constructor đó. Các account được khai báo bằng annotation hàm có sẵn trong vector tx.accounts. Ví dụ, bạn sẽ dùng tx.accounts.ichigo để truy cập account được khai báo là @account(ichigo). Thao tác này sẽ trả về struct tích hợp AccountInfo. Struct này tuân theo cấu trúc mà chúng ta đã trình bày trong phần “Tìm hiểu mô hình account”. Cách đặt tên hơi khác:

  • key: địa chỉ hoặc khóa công khai của account. Thuộc kiểu address
  • lamports: số dư lamport của account. Thuộc kiểu uint64
  • data: dữ liệu của account. Thuộc kiểu bytes
  • owner: chủ sở hữu account. Thuộc kiểu address
  • rent_epoch: epoch tiếp theo khi account đến hạn trả tiền thuê. Thuộc kiểu uint64
  • is_signer: xác định account có ký transaction hay không. Thuộc kiểu bool
  • is_writable: xác định account có thể ghi trong transaction này hay không. Thuộc kiểu bool
  • executable: xác định account có phải là chương trình hay không. Thuộc kiểu bool

Hạn chế

Các điểm không tương thích chính giữa Solang và quy trình phát triển Ethereum truyền thống gồm:

  • msg.sender không khả dụng trên Solana. Với mô hình account, một contract Rust có thể truy cập nhiều data account khác nhau, vậy account nào trong số đó được xem là bên gọi? Trong nhiều trường hợp, chúng ta không thể xác định một account duy nhất là bên gọi. Ngoài ra, runtime không có cơ chế truy xuất account của bên gọi
  • Không có hàm ecrecover(), nhưng có hàm signatureVerify() để kiểm tra chữ ký ed25519.
  • Các câu lệnh try-catch không hoạt động. Runtime sẽ dừng thực thi và hoàn tác toàn bộ transaction nếu bất kỳ lệnh gọi bên ngoài hoặc thao tác tạo contract nào thất bại.
  • Định nghĩa lỗi và thao tác hoàn tác kèm thông báo lỗi chưa hoạt động
  • Việc chuyển giá trị native bằng lệnh gọi hàm không hoạt động.
  • Nhiều thành phần tích hợp của Yul không khả dụng. Solang hỗ trợ phần lớn thành phần tích hợp, nhưng các thao tác về bộ nhớ và chain chưa được triển khai.
  • Định dạng ERC-20 hiện chưa được hỗ trợ. SPL Token được định nghĩa theo Token Program. Token Program là cách native của Solana để tạo, mint, chuyển và burn token. Tệp spl_token.sol cần được sao chép vào cây mã nguồn và import tại nơi cần dùng thư viện SplToken

Ngoài ra, các thanh ghi của SVM có độ rộng 64 bit, nghĩa là số nguyên 64 bit (tức uint64 và int64) được ưu tiên hơn số nguyên 256 bit. Một thao tác với kiểu dữ liệu rộng hơn 64 bit, chẳng hạn uint256 hoặc int256, sẽ được tách thành nhiều thao tác. Điều này khiến chúng chậm hơn và tiêu tốn nhiều đơn vị tính toán hơn.

Về địa chỉ, một literal địa chỉ phải được chỉ định bằng cú pháp address"36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D". Cú pháp hex của Ethereum (ví dụ: 0xE0f5206BBD039e7b0592d8918820024e2a7437b9) không được hỗ trợ. Mọi số dư và giá trị trên Solana đều có độ rộng 64 bit. Điều này có nghĩa các hàm tích hợp dành cho địa chỉ (tức .balance(), .transfer() và .send()) sử dụng số nguyên 64 bit.

Mặc dù Solang mở ra một lộ trình hấp dẫn để các nhà phát triển EVM bước vào hệ sinh thái Solana, công cụ này có một số hạn chế cần được cân nhắc kỹ. Việc chuyển sang mô hình dựa trên account của Solana không đơn thuần là thay đổi cú pháp — đó là thay đổi căn bản trong logic smart contract. Một số hàm, mẫu lập trình và tính năng dành riêng cho EVM không khả dụng với Solang. Nhà phát triển không thể chuyển một smart contract Ethereum sang Solang và kỳ vọng nó hoạt động mà không cần điều chỉnh đáng kể. Các tính năng còn thiếu, như chưa có định nghĩa lỗi phù hợp và thao tác hoàn tác kèm thông báo lỗi, có thể gây ra vấn đề nghiêm trọng. Tuy nhiên, cần nhận thức rằng Solang là một công cụ liên tục phát triển, với mỗi bản cập nhật đều nhằm cải thiện trải nghiệm của nhà phát triển Solidity trên Solana. Solang mang lại một số lợi thế riêng biệt để cải thiện trải nghiệm này.

Ưu điểm

Bất chấp những hạn chế này, có nhiều hàm tích hợp và lựa chọn thiết kế giúp cải thiện trải nghiệm của nhà phát triển. Ví dụ, các contract được phát triển bằng Solang có thể tương tác với chương trình Anchor. Có thể thực hiện điều này bằng cách tạo một interface Solidity từ IDL của chương trình Anchor. IDL là viết tắt của “Ngôn ngữ mô tả interface”. Về cơ bản, đây là một tệp JSON chứa toàn bộ đặc tả của một chương trình. Tệp này bao gồm mọi thông tin cần thiết để tương tác với chương trình Anchor. Anchor tự động tạo IDL khi phát triển chương trình bằng framework của mình. Điều này rất giống ABI trên Ethereum. Để tạo interface Solidity từ IDL, hãy dùng lệnh sau: solang idl [-output directory] [IDL file]. Sau đó, có thể import tệp bằng cú pháp import “...”;.

Solang cung cấp thư viện Solana, một bộ thư viện để các contract Solidity tương tác với những instruction dành riêng cho Solana. Solang cung cấp thư viện SPL Token để mint, burn và chuyển token. Có thể xem đây là thư viện tương đương với ERC-20 và ERC-721. Solang cũng cung cấp thư viện System Instructions để nhà phát triển có thể tương tác với System Program của Solana.

Solang cũng bao gồm một số chức năng tích hợp có thể được import bằng solana. Trong đó có các struct AccountMeta và AccountInfo. Struct AccountMeta dùng để chỉ định những account cần được truyền cho bên được gọi trong một lệnh gọi bên ngoài (tức CPI). Struct AccountMeta có cấu trúc sau:

  • pubkey: địa chỉ hoặc khóa công khai của account. Thuộc kiểu address
  • is_writable: xác định bên được gọi có thể ghi vào account này hay không. Thuộc kiểu bool
  • is_signer: xác định bên được gọi có thể giả định account này đã ký transaction hay không. Thuộc kiểu bool

Nếu đối số accounts bị lược bỏ trong một lệnh gọi bên ngoài, trình biên dịch Solang sẽ tự động tạo một mảng AccountMeta. Điều này chỉ hoạt động nếu hàm được khai báo là external. Nếu không, mảng AccountMeta phải được tạo thủ công theo thứ tự account được chỉ định trong IDL. Nếu một lệnh gọi nhất định không cần account, hãy truyền vào một vector trống: {accounts: []}. Tài liệu Solang cung cấp một ví dụ rõ ràng về cách xây dựng mảng AccountMetas:

Mã
function build_this() external {
	// When calling a constructor from an external function, the data account for the contract
	// 'BeingBuilt' should be passed as the 'BeingBuilt_dataAccount' in the client code.
	BeingBuilt.new("my_seed");
}

function build_that(address data_account, address payer_account) public {
	AccountMeta[3] metas = [
		AccountMeta({
			pubkey: data_account,
      is_signer: true,
      is_writable: true
		}),
    AccountMeta({
    	pubkey: payer_account,
      is_signer: true,
      is_writable: true
    }),
    AccountMeta({
      pubkey: address"11111111111111111111111111111111",
      is_writable: false,
      is_signer: false
    })
  ];
  BeingBuilt.new{accounts: metas}("my_seed");

	// No accounts are needed in this call, so we pass an empty vector.
	BeingBuilt.say_this{accounts: []}("It's summertime!");
}

Solang cũng có các hàm tích hợp để:

Solang thu hẹp khoảng cách giữa Solana và Ethereum bằng cách cung cấp một trình biên dịch với bộ công cụ phong phú, giúp nhà phát triển EVM chuyển đổi dễ dàng hơn. Dù có những hạn chế, Solang cung cấp một số tính năng để nâng cao trải nghiệm của nhà phát triển, bao gồm khả năng tương tác với chương trình Anchor, truy cập các thư viện dành riêng cho Solana và sử dụng các hàm tích hợp. Việc kết hợp những khái niệm quen thuộc như IDL và tiêu chuẩn token còn giúp giảm độ dốc học tập. Không phải lo lắng hay tối ưu phí gas cũng là một điểm cộng đáng hoan nghênh. Solang đại diện cho một bước tiến quan trọng hướng tới khả năng tương tác giữa Solana và Ethereum. Với các nhà phát triển EVM muốn mở rộng sang thế giới Solana có hiệu năng cao, Solang là một công cụ đáng cân nhắc.

Neon EVM

Solang không phải lựa chọn duy nhất cho các nhà phát triển Solidity muốn xây dựng trên Solana. Neon EVM tự mô tả là EVM có thể song song hóa đầu tiên trên thế giới. Đây là một môi trường Ethereum tương thích hoàn toàn trên Solana. Đó là giải pháp cộng hưởng dành cho bất kỳ ai muốn mở rộng quy mô dApp Ethereum trên Solana theo cách thân thiện với nhà phát triển. Nhà phát triển có thể triển khai dApp mà không cần cấu hình lại smart contract, vẫn dùng các ngôn ngữ và công cụ quen thuộc.

Kiến trúc

Neon EVM gồm ba thành phần chính: chương trình Neon EVM, Neon Proxy và Neon DAO.

Neon EVM là một chương trình Solana tiếp nhận các transaction tương tự Ethereum và xử lý chúng trên Solana theo quy tắc của EVM. Những transaction tương tự Ethereum được gửi đến Neon EVM này được gọi là Neon Transactions. Chúng là một tập con của các phương thức JSON RPC theo Ethereum JSON-RPC API.

Neon Proxy cho phép nhà phát triển Ethereum chuyển dApp sang Neon với ít thay đổi nhất. Neon Proxy đóng gói transaction EVM vào transaction Solana, hoạt động như một giải pháp container hóa cho Neon Operator. Các operator này chạy máy chủ Neon Proxy, nhận thanh toán bằng NEON và thanh toán trong hệ sinh thái Solana bằng SOL. NEON vừa là token tiện ích vừa là token quản trị: Neon Operator thu NEON để trả phí gas cần thiết cho việc thực thi transaction, còn chủ sở hữu có thể tham gia Neon DAO.

Neon DAO là mô hình quản trị do cộng đồng dẫn dắt, được thiết kế để trao quyền cho chủ sở hữu token NEON trong quá trình ra quyết định của Neon EVM. DAO gồm người dùng, operator, người đóng góp, nhà phát triển lõi và nhà phát triển ứng dụng, cùng nhau thảo luận về các quy tắc quản trị và sự phát triển của giao thức. DAO hoạt động thông qua nhiều hội đồng phi tập trung tập trung vào hệ sinh thái, hoạt động phát triển và bảo mật. Mỗi hội đồng hỗ trợ ra quyết định cộng tác và thẩm định đề xuất trong lĩnh vực tương ứng. Hội đồng tập trung vào hệ sinh thái giám sát sự tăng trưởng bền vững của hệ sinh thái, quản lý quỹ tài trợ và các sáng kiến. Hội đồng tập trung vào phát triển xử lý các nâng cấp kỹ thuật cho chương trình Neon và các biện pháp can thiệp khẩn cấp. Hội đồng tập trung vào bảo mật bảo vệ ngân quỹ của Neon và chương trình Neon trước các mối đe dọa tiềm ẩn.

Khả năng tương thích EVM

Neon EVM hỗ trợ tương tác EVM trên Solana bằng cách:

  • Triển khai phần lớn các phương thức Ethereum JSON-RPC API
  • Sử dụng một proxy chuyên biệt để xử lý các lệnh gọi Ethereum
  • Thích ứng với những khác biệt và hạn chế do kiến trúc Solana đặt ra

Tương tác với Neon EVM tương tự như tương tác với bất kỳ EVM nào khác. Nhà phát triển có thể dùng các phương thức RPC API quen thuộc được gửi đến Neon Proxy, tạo ra trải nghiệm liền mạch. Các tính năng chính gồm:

  • Tương thích với smart contract Solidity và Vyper, cũng như các công cụ phát triển Ethereum tiêu chuẩn như Metamask, Foundry và Remix
  • Hỗ trợ nguyên dạng phần lớn opcode Ethereum
  • Chấp nhận yêu cầu transaction Ethereum loại 0 / legacy. Transaction EIP-1559 hiện chưa được hỗ trợ

Dĩ nhiên, Neon EVM cần một số điều chỉnh để hoạt động chính xác trên Solana. Các khác biệt đáng chú ý gồm:

  • Neon EVM hỗ trợ tất cả contract biên dịch sẵn được định nghĩa trên evm.code. Tuy nhiên, các contract Solidity chứa những lệnh gọi sau sẽ không được thực thi: bigModExp, bn256Add, bn256ScalarMult và bn256Pairing. Trong tương lai, Neon EVM cần triển khai các lệnh gọi hệ thống Solana để hỗ trợ những contract này
  • Dù phần lớn opcode được hỗ trợ nguyên dạng, các opcode COINBASE, PREVRANDAO (FKA DIFFICULTY), GASLIMIT, BASEFEE và GAS thì không. Chúng được gọi là opcode biến thể và đã được điều chỉnh để sử dụng trong Neon EVM.
  • Mức tiêu thụ gas và cách tính phí khác với Ethereum. Nhìn chung, chi phí thấp hơn nhờ vai trò của Solana như lớp quyết toán
  • Các phương thức transfer() và send() của Solidity không an toàn trước tái nhập trong Neon EVM do cách tính gas khác nhau
  • Mô hình account của Solana ảnh hưởng đến bộ nhớ smart contract, với chức năng lưu trữ và quyền truy cập khác nhau đối với account có thể thực thi và không thể thực thi
  • Neon EVM dùng transaction có phiên bản, giới hạn số lượng account tối đa trong một transaction là 64
  • Neon EVM dùng Berkeley Packet Filter (BPF) của Solana với giới hạn bộ nhớ heap là 256 KB. Điều này hạn chế kích thước lệnh gọi contract và đòi hỏi các chiến lược tối ưu hóa để quản lý hiệu quả mức sử dụng bộ nhớ
  • Các hàm dựa trên thời gian như block.number và block.timestamp hoạt động khác đi. Nhà phát triển được khuyến cáo đặc biệt không nên dùng chúng khi phát triển trên Neon EVM

Mặc dù Neon EVM cung cấp một môi trường quen thuộc và tương thích, nhà phát triển EVM phải nhận thức và thích ứng với những khác biệt chính để di chuyển và xây dựng thành công trên Solana.

Kết nối với Neon RPC

Nhà phát triển có thể dễ dàng kết nối với Neon RPC bằng Chainlist. Tại đây, nhà phát triển có thể kết nối với Neon EVM Mainnet hoặc Devnet. Nhấp vào Connect Wallet trên hộp thoại Mainnet hoặc Devnet, rồi nhấp Approve khi ví bật lên.

Người dùng nên chọn operator tối ưu trước khi gửi transaction đến Neon EVM. Mở rộng thông tin chi tiết của thẻ để xem các endpoint RPC hiện có cho từng mạng:

Nếu chọn một Operator khác với operator mặc định được cung cấp khi kết nối ví, bạn sẽ cần kết nối thủ công. Tài liệu Neon EVM cung cấp hướng dẫn toàn diện về cách kết nối với Proxy bằng Foundry, Hardhat, Remix và Truffle. Chúng ta sẽ trình bày cách kết nối bằng Foundry trong phần triển khai.

Sau khi kết nối, nhà phát triển có thể dùng Neon Faucet để nhận NEON hoặc các token thử nghiệm ERC-20 khác. Nhà phát triển cũng có thể dùng endpoint request_neon để yêu cầu token theo chương trình:

Mã
curl -i -X POST \
	-d '{"wallet": "Your wallet", "amount": 1}' \
	'http://localhost:3333/request_neon'

Lệnh này gửi một yêu cầu POST để nhận token vào địa chỉ ví được chỉ định.

Vòng đời transaction và phí gas

Có ba bước chính để thực thi một transaction từ dApp Ethereum trên Solana thông qua Neon EVM:

  • Người dùng khởi tạo một transaction tương tự Ethereum đã được ký và gửi đến endpoint Neon RPC
  • Transaction được chuyển đến Neon Proxy qua Ethereum API. Proxy ước tính lượng gas cần để thực thi transaction, bắt đầu phát sóng bằng cách gói transaction tương tự Ethereum vào một transaction Solana rồi gửi transaction đã gói đến Neon EVM. Quá trình này tạo ra một biên nhận Solana và một biên nhận Neon EVM tương ứng cho transaction. Smart contract Neon mở gói transaction, xác minh chữ ký người dùng và tải trạng thái EVM từ bộ nhớ Solana. Transaction được thực thi bên trong BPF của Solana
  • Solana và Neon EVM cập nhật trạng thái để hoàn tất yêu cầu transaction

Đây là toàn bộ vòng đời transaction trong Neon EVM, từ lúc khởi tạo đến khi thực thi. Nhà phát triển có thể truy cập NeonScan để xem các transaction và block mới nhất, đồng thời truy vấn account, token, block hoặc hash transaction.

Nhà phát triển cũng có thể gửi transaction không mất phí gas. Tính năng này được triển khai để hỗ trợ người dùng không có đủ token NEON trả phí cho transaction ban đầu. Nhà phát triển có thể nhận gói khởi đầu gồm các transaction không mất phí gas bằng cách liên hệ info@neonevm.org. Proxy Operator do nhà phát triển chọn vẫn xử lý các transaction này, nhưng Neon sẽ chi trả chi phí transaction. Thông thường, mỗi account Neon mới được cung cấp tối thiểu ba transaction không mất phí gas.

Quy trình dành cho transaction không mất phí gas như sau:

  • Người dùng cuối khởi tạo transaction qua dApp
  • dApp yêu cầu mức giá gas hiện tại từ Proxy Operator đã chọn. Nếu đủ điều kiện, Proxy Operator đánh dấu account Neon cho một số lượng transaction không mất phí gas cụ thể
  • Với các transaction đó, dApp sẽ hiển thị chi phí gas bằng 0
  • Người dùng cuối ký transaction mà không phải trả phí gas
  • Proxy Operator thực thi transaction, còn phí gas bằng SOL do Neon Foundation chi trả

Tài liệu Neon EVM cung cấp đoạn trích sau để minh họa cách yêu cầu một transaction không mất phí gas:

Mã
try {
	// Get gasless transaction if user account is eligible
  const rawGasPrice = await axios.post(rpcApiUrl, {
  	method: 'neon_gasPrice',
    params: [{ from: address }],
    jsonrpc: "2.0",
    id: new Date().getTime()
   })

   tx.gasPrice = rawGasPrice.data?.result;
	} catch (e) {
  	//Else, get standard GAS price
   	setError('Can\'t retrieve gas price for transaction')

    const rawGasPrice = await web3.eth.getGasPrice();

    tx.gasPrice = web3.utils.toHex(rawGasPrice);
} finally {
    setTx(tx)
}

NeonPass

NeonPass là công cụ chuyển token giữa Solana và Neon EVM. Công cụ này cho phép chuyển tài sản liền mạch giữa Associated Token Account của Solana và account token ERC-20 của Neon EVM. NeonPass dùng contract interface và bộ nhớ account chuyên biệt của Neon EVM. Token Solana Program Library (SPL) được đóng gói vào một interface ERC-20 bên trong factory contract của Neon EVM. Điều này cho phép lưu trữ SPL trong các account token ERC-20 tương thích với dApp Solidity. NeonPass cho phép chuyển token hai chiều giữa account Solana và Neon EVM. Không giống các bridge truyền thống vốn khóa tài sản rồi mint tài sản mới, NeonPass chuyển trực tiếp token giữa hai loại account. Điều này tạo ra quá trình chuyển đổi liền mạch giữa token Solana và Neon EVM.

Triển khai

Nhà phát triển có thể triển khai lên Neon EVM bằng Hardhat, Foundry, Truffle và Remix. Vì cách dễ nhất để dùng Solang là thông qua Anchor, toàn bộ hoạt động kiểm thử đều được thực hiện bằng TypeScript. Tuy nhiên, cuối cùng chúng ta cũng có thể kiểm thử và triển khai dApp Solidity lên Solana qua Foundry, dành cho tất cả những người tuyệt đối yêu thích Solidity.

Trước tiên, hãy đảm bảo bạn có một ví tương thích với EVM đã kết nối với Neon EVM Devnet. Sau đó, clone dự án Foundry mẫu của Neon và chuyển đến thư mục dự án:

Mã
git clone https://github.com/neonlabsorg/neon-tutorials
cd neon-tutorials/foundry

Tiếp theo, cài đặt Foundryup, trình cài đặt bộ công cụ Foundry, rồi chạy foundryup để cài đặt các binary biên dịch sẵn mới nhất (nightly) (tức force, cast, anvil và chisel):

Mã
curl -L https://foundry.paradigm.xyz | bash
foundryup

Cài đặt các thư viện bắt buộc:

Mã
forge install foundry-rs/forge-std --no-commit
forge install openzeppelin/openzeppelin-contracts --no-commit

Bây giờ, hãy lấy khóa riêng tư cho account ví. Ví dụ, trong Metamask, bạn có thể xem khóa riêng tư bằng cách nhấp vào menu hamburger rồi chuyển đến Account Details > Show Private Key. Hệ thống sẽ yêu cầu bạn nhập mật khẩu. Nhấp Confirm để truy cập khóa riêng tư của account. Hãy nhớ không chia sẻ khóa này với bất kỳ ai và thực hiện các biện pháp cần thiết để bảo vệ khóa.

Sau đó, tạo một tệp .env với các biến sau:

Mã
RPC_URL_DEVNET=https://devnet.neonevm.org
CHAIN_ID_DEVNET=245022926
RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
CHAIN_ID_MAINNET=245022934
PRIVATE_KEY=
VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api

Thay <YOUR_PRIVATE_KEY> bằng khóa riêng tư của bạn rồi chạy source .env.

Để biên dịch các contract của dự án, hãy chuyển đến thư mục src và chạy forge build. Console sẽ trả về thông báo cho biết quá trình chạy trình biên dịch đã thành công. Cũng có thể kiểm thử các contract bằng lệnh forge test. Để triển khai contract của dự án, hãy chạy lệnh sau:

Mã
forge create --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY src/TestERC20/TestERC20.sol:TestERC20 --constructor-args "Test ERC20 Token" "TERC20" --legacy

Bạn sẽ thấy đầu ra tương tự như sau:

Mã
[⠰] Compiling...
No files changed, compilation skipped
Deployer: 0x4455E84Eaa56a01676365D4f86348B311969a4f4
Deployed to: 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9
Transaction hash: 0x6de9dab8a526cbac33008056d185b93dff725605efb791bf116b6bece4f0c486

Để xác minh contract, hãy chạy lệnh sau:

Mã
forge verify-contract --chain-id $CHAIN_ID_DEVNET  src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout

Thay <contract_address> bằng địa chỉ smart contract của bạn. Bạn sẽ nhận được phản hồi OK kèm URL trỏ đến địa chỉ contract trên BlockScout, trình khám phá Devnet của Neon. Bạn cũng có thể cấu hình tệp .env để dùng NeonScan thay cho BlockScout; NeonScan cũng hỗ trợ devnet.

Ưu điểm và hạn chế

Nhà phát triển muốn có trải nghiệm phát triển tương tự Ethereum nên chọn Neon EVM. Đây là môi trường tương thích với EVM, gửi các transaction tương tự Ethereum và sử dụng những công cụ quen thuộc. Các tính năng như NeonPass, khả năng hỗ trợ phần lớn opcode EVM và việc cung cấp transaction không mất phí gas giúp quá trình chuyển sang Solana dễ dàng hơn nhiều. Tuy nhiên, Neon EVM không hoàn hảo. Neon EVM có một số hạn chế, chẳng hạn như phải thay đổi logic smart contract để thích ứng với hạ tầng Solana, phải hoạt động trong các giới hạn của Berkeley Packet Filter (BFP) và mô hình account của Solana, cũng như một số hạn chế đối với opcode và contract biên dịch sẵn. Hiểu và xử lý được những khác biệt tinh tế này là yếu tố thiết yếu để triển khai thành công lên Solana từ một môi trường tương thích với EVM.

Các đợt di chuyển trước đây

Một giao thức Ethereum lớn phải hoàn thành nhiều nhiệm vụ phức tạp để triển khai trên một blockchain không tương thích EVM. Cụ thể, họ phải tuyển các kỹ sư không chuyên Solidity để xây dựng lại toàn bộ cơ sở mã từ đầu, tìm đối tác kiểm toán đáng tin cậy, kiểm toán lại cơ sở mã mới và điều chỉnh các hợp đồng quản trị để thực thi quyết định của DAO. Những công việc này có thể tiêu tốn hàng triệu đô la và đòi hỏi nhiều tháng làm việc chuyên sâu. Điều đó không khả thi với hầu hết các dự án. Tuy nhiên, đã có những dự án thực hiện thành công.

Helium là một mạng LoRaWAN hướng đến việc tạo ra cơ sở hạ tầng không dây phi tập trung để hỗ trợ các thiết bị Internet vạn vật (IoT). Mạng này sử dụng các hotspot, tức những thiết bị nhỏ, tiêu thụ ít điện năng, tương tự các trạm phát sóng di động thu nhỏ và có thể kết nối với những hotspot khác ở khoảng cách xa. Ban đầu hoạt động trên blockchain Lớp 1 (L1) riêng, đội ngũ phát triển Helium đã đề xuất chuyển sang Solana thông qua HIP 70. Việc này sẽ giúp Helium đạt thời gian hoạt động cao hơn, khả năng kết hợp tốt hơn và trải nghiệm người dùng nhanh hơn, đồng thời duy trì mức độ bảo mật cao và chi phí sử dụng thấp. Cộng đồng đã bỏ phiếu áp đảo ủng hộ đề xuất và Helium chuyển sang Solana vào tháng 4 năm 2023. COO Scott Sigel của Helium mô tả đợt di chuyển này là một sự kiện nhàm chán — không có sự cố nào xảy ra với mạng hoặc cơ sở hạ tầng của Helium. Đó là giấc mơ của mọi kỹ sư. Đội ngũ cũng trình bày toàn bộ quy trình di chuyển trong một loạt hướng dẫn thuộc tài liệu của họ. Đợt di chuyển của Helium đã thành công lớn và mang lại nhiều lợi ích cho cộng đồng.

Đợt di chuyển này không phải là trường hợp cá biệt. The Render Network, nền tảng kết xuất GPU phi tập trung đầu tiên trên thế giới, đã nâng cấp thành công cơ sở hạ tầng cốt lõi từ Ethereum lên Solana vào tháng 11 năm 2023. Cộng đồng đã bỏ phiếu ủng hộ RNP-002 để chuyển sang Solana. Nhà sáng lập Render, Jules Urbach, mô tả đợt di chuyển này là một thời khắc bước ngoặt. Ông cho biết: “Tốc độ giao dịch đáng kinh ngạc, chi phí thấp và cam kết đối với kiến trúc quy mô web của Solana khiến nền tảng này trở thành lựa chọn hoàn hảo cho Render Network khi chúng tôi tiếp tục xây dựng cơ sở hạ tầng metaverse phi tập trung có khả năng mở rộng.”

Đợt di chuyển của Render không gây ảnh hưởng quá tiêu cực đến người dùng. Người dùng có thể chuyển tiền từ Ethereum sang Solana bằng Upgrade Assistant của Render. Họ kết nối ví Ethereum, nhập số lượng RNDR muốn di chuyển rồi chờ token được chuyển đến ví Solana đã chỉ định. 

Maker là một dự án Ethereum tiêu biểu. Họ hướng đến việc khai phá tiềm năng của tài chính phi tập trung bằng Maker Platform, một nền tảng toàn diện được thiết kế để tăng cường quyền tự chủ kinh tế và khả năng tiếp cận bình đẳng với thị trường tài chính toàn cầu. Nền tảng này gồm MakerDAO để quản lý dự án Maker và giao thức Maker dành cho DAI, “đồng tiền trung lập đầu tiên trên thế giới và stablecoin phi tập trung hàng đầu.” Rune Christensen, nhà sáng lập Maker, đã đăng trên Twitter về việc sử dụng một bản fork của cơ sở mã Solana để phát triển một appchain cho Maker: 

Về bản chất, các đợt di chuyển đều phức tạp. Bất chấp chi phí về tiền bạc, danh tiếng và thời gian khi chuyển toàn bộ cơ sở hạ tầng của một dự án từ Ethereum sang Solana, các dự án vẫn đang chọn Solana. Với những công cụ như Solang và Neon EVM, quá trình di chuyển không nhất thiết phải phức tạp. Tương tự đợt di chuyển của Helium, quá trình này có thể diễn ra bình lặng và hầu như không gây ảnh hưởng tiêu cực đến tài sản của người dùng, như trường hợp Render Network. Solana là blockchain có hiệu năng cao nhất trên thị trường, được xây dựng cho quy mô web. Đây là nơi để phát triển, và ngày càng nhiều dự án nhận ra điều đó.

Kết luận

Solidity là lingua franca trong lĩnh vực phát triển hợp đồng thông minh. EVM đã là môi trường hợp đồng thông minh thống trị kể từ khi ra đời. Tuy nhiên, EVM vẫn có những điểm yếu. Các ứng dụng cấp độ người tiêu dùng ở quy mô web cần một mạng có thông lượng cao và độ trễ thấp để hỗ trợ hoạt động. Môi trường đơn luồng dựa trên gas đầy biến động của Ethereum không thể hỗ trợ một dự án Mạng lưới Cơ sở hạ tầng Vật lý Phi tập trung (DePIN) có thông lượng cao như Helium. 

Trước những thách thức này, Solana nổi lên như một giải pháp thay thế mạnh mẽ. Cách tốt nhất để khai thác trọn vẹn lợi ích thực sự của Solana là trực tiếp xây dựng trên Solana. Nhờ những bước phát triển gần đây, các công cụ như Solang và Neon EVM cho phép những nhà phát triển EVM quan tâm thực hiện quá trình di chuyển bằng các công cụ và ngôn ngữ quen thuộc. Bài viết này cung cấp hướng dẫn toàn diện về kiến trúc của Solana, cách kiến trúc này so sánh với Ethereum và đề xuất cách một nhà phát triển EVM có thể bắt đầu phát triển trên Solana. Solana là blockchain có hiệu năng cao nhất trên thị trường. Solana đang ngày càng có thêm động lực phát triển, thu hút sự quan tâm và sở hữu nhiều ứng dụng cấp độ người tiêu dùng uy tín. Tại sao phải chờ Ethereum mở rộng quy mô khi bạn có thể tận hưởng lợi ích của một blockchain nhanh và có khả năng mở rộng ngay hôm nay?

Nếu đã đọc đến đây, cảm ơn bạn, anon! Hãy nhập địa chỉ email bên dưới để không bao giờ bỏ lỡ thông tin cập nhật về những điều mới nhất trên Solana. Bạn đã sẵn sàng tìm hiểu sâu hơn chưa? Hãy tham gia Discord của chúng tôi để bắt đầu xây dựng tương lai trên blockchain có hiệu năng cao nhất ngay hôm nay.

Tài nguyên bổ sung

Bài viết liên quan

Đăng ký nhận tin từ Helius

Luôn cập nhật những thông tin mới nhất về phát triển Solana và nhận thông báo khi chúng tôi đăng bài

Hình ảnh phóng to