Bài viết này là bài đầu tiên trong chuỗi mã nguồn Geth, qua chuỗi này, chúng ta sẽ xây dựng một khung nghiên cứu về việc thực hiện Geth, người phát triển có thể dựa trên khung này để nghiên cứu sâu về những phần mà họ quan tâm. Chuỗi này có tổng cộng sáu bài viết, trong bài đầu tiên, sẽ nghiên cứu cấu trúc thiết kế của khách hàng Geth ở tầng thực thi và quy trình khởi động nút Geth. Mã Geth được cập nhật rất nhanh, mã mà bạn thấy sau này có thể khác nhau, nhưng thiết kế tổng thể vẫn tương đối nhất quán, mã mới cũng có thể được đọc theo cách tương tự.
01\Khách hàng Ethereum
Trước khi thực hiện nâng cấp The Merge, Ethereum chỉ có một khách hàng, khách hàng này chịu trách nhiệm thực hiện giao dịch và cũng sẽ chịu trách nhiệm về sự đồng thuận của blockchain, đảm bảo blockchain tạo ra các khối mới theo một thứ tự nhất định. Sau khi nâng cấp The Merge, khách hàng Ethereum đã được chia thành tầng thực thi và tầng đồng thuận, tầng thực thi chịu trách nhiệm thực hiện giao dịch, duy trì trạng thái và dữ liệu, trong khi tầng đồng thuận chịu trách nhiệm thực hiện chức năng đồng thuận, tầng thực thi và tầng đồng thuận giao tiếp với nhau thông qua API. Tầng thực thi và tầng đồng thuận có các quy định riêng, khách hàng có thể sử dụng các ngôn ngữ khác nhau để thực hiện, nhưng phải tuân theo các quy định tương ứng, trong đó Geth là một trong những cách thực hiện của khách hàng tầng thực thi. Hiện tại, các khách hàng tầng thực thi và tầng đồng thuận phổ biến có các cách thực hiện như sau:
Thực thi
Geth: Được duy trì bởi đội ngũ được quỹ Ethereum tài trợ trực tiếp, được phát triển bằng ngôn ngữ Go, là khách hàng được công nhận ổn định nhất, đã được thử nghiệm qua thời gian.
Nethermind: Được phát triển và duy trì bởi đội ngũ Nethermind, được phát triển bằng ngôn ngữ C#, đã được quỹ Ethereum và cộng đồng Gitcoin tài trợ trong giai đoạn đầu.
Besu: Ban đầu được phát triển bởi đội ngũ PegaSys của ConsenSys, hiện là dự án của cộng đồng Hyperledger, được phát triển bằng ngôn ngữ Java.
Erigon: Được phát triển và duy trì bởi đội ngũ Erigon, được tài trợ bởi Quỹ Ethereum và BNB Chain. Ra đời từ việc phân nhánh Geth vào năm 2017, mục tiêu là nâng cao tốc độ đồng bộ và hiệu quả ổ đĩa.
Reth: Được phát triển dưới sự dẫn dắt của Paradigm, ngôn ngữ phát triển là Rust, nhấn mạnh vào tính mô-đun và hiệu suất cao, hiện đã gần đạt trạng thái trưởng thành, có thể sử dụng trong môi trường sản xuất.
Tầng đồng thuận
Prysm: Được duy trì bởi Prysmatic Labs, là một trong những client lớp đồng thuận đầu tiên của Ethereum, được phát triển bằng ngôn ngữ Go, tập trung vào tính khả dụng và an toàn, đã nhận được tài trợ từ Quỹ Ethereum trong giai đoạn đầu.
Lighthouse: Được đội ngũ Sigma Prime duy trì, phát triển bằng ngôn ngữ Rust, nổi bật với hiệu suất cao và an toàn cấp doanh nghiệp, phù hợp với các tình huống tải cao.
Teku: Được phát triển bởi đội ngũ PegaSys của ConsenSys, sau đó trở thành một phần của cộng đồng Hyperledger Besu, được phát triển bằng ngôn ngữ Java.
Nimbus: Được phát triển và duy trì bởi đội ngũ Status Network, sử dụng ngôn ngữ Nim, được tối ưu hóa cho các thiết bị hạn chế tài nguyên (như điện thoại di động, thiết bị IoT), mục tiêu là để thực hiện hoạt động nhẹ trên các hệ thống nhúng.
02\Giới thiệu về lớp thực thi
Có thể coi lớp thực thi Ethereum như một máy trạng thái được điều khiển bởi giao dịch, chức năng cơ bản nhất của lớp thực thi là cập nhật dữ liệu trạng thái thông qua việc thực thi giao dịch bằng EVM. Ngoài việc thực thi giao dịch, còn có các chức năng khác như lưu trữ và xác minh khối và dữ liệu trạng thái, chạy mạng p2p và duy trì hồ giao dịch.
Giao dịch được người dùng (hoặc chương trình) tạo ra theo định dạng được định nghĩa bởi tiêu chuẩn của lớp thực thi Ethereum, người dùng cần ký giao dịch. Nếu giao dịch hợp lệ (Nonce liên tiếp, chữ ký đúng, phí gas đủ, logic nghiệp vụ đúng), thì giao dịch cuối cùng sẽ được EVM thực thi, từ đó cập nhật trạng thái của mạng Ethereum. Ở đây, trạng thái chỉ tập hợp các cấu trúc dữ liệu, dữ liệu và cơ sở dữ liệu, bao gồm địa chỉ tài khoản bên ngoài, địa chỉ hợp đồng, số dư địa chỉ cũng như mã và dữ liệu.
Lớp thực thi chịu trách nhiệm thực hiện giao dịch và duy trì trạng thái sau khi thực hiện giao dịch, trong khi lớp đồng thuận chịu trách nhiệm chọn giao dịch nào để thực hiện. EVM là hàm chuyển đổi trạng thái trong máy trạng thái này, đầu vào của hàm có thể đến từ nhiều nguồn khác nhau, có thể đến từ thông tin khối mới nhất do lớp đồng thuận cung cấp hoặc có thể đến từ khối được tải xuống từ mạng p2p.
Lớp đồng thuận và lớp thực thi giao tiếp qua Engine API, đây là cách giao tiếp duy nhất giữa lớp thực thi và lớp đồng thuận. Nếu lớp đồng thuận có quyền tạo khối, nó sẽ thông qua Engine API để cho lớp thực thi tạo ra khối mới; nếu không có quyền tạo khối, nó sẽ đồng bộ khối mới nhất để lớp thực thi xác minh và thực hiện, từ đó duy trì sự đồng thuận với toàn bộ mạng Ethereum.
Lớp thực thi về mặt logic có thể được chia thành 6 phần:
EVM: Chịu trách nhiệm thực hiện giao dịch, việc thực hiện giao dịch cũng là cách duy nhất để thay đổi số trạng thái.
Lưu trữ: Chịu trách nhiệm về việc lưu trữ state cũng như dữ liệu khối và các dữ liệu khác.
Hồ giao dịch: dùng để lưu trữ tạm thời các giao dịch được người dùng gửi, và sẽ được truyền bá qua mạng p2p giữa các Nút khác nhau.
mạng p2p: được sử dụng để phát hiện Nút, đồng bộ giao dịch, tải xuống khối, v.v.
Dịch vụ RPC: Cung cấp khả năng truy cập Nút, chẳng hạn như người dùng gửi giao dịch đến Nút, tương tác giữa lớp đồng thuận và lớp thực thi.
BlockChain：Chịu trách nhiệm quản lý dữ liệu blockchain của Ethereum
Hình dưới đây hiển thị quy trình chính của lớp thực thi, cũng như chức năng của từng phần:
Đối với lớp thực thi (tạm thời chỉ thảo luận về Full Node), có ba quy trình quan trọng:
Nếu là nút mới tham gia vào Ethereum, cần phải đồng bộ hóa khối và dữ liệu trạng thái từ các nút khác thông qua mạng p2p, nếu là Full Sync, sẽ bắt đầu tải từng khối từ khối Genesis, xác thực khối và tái tạo cơ sở dữ liệu trạng thái thông qua EVM, nếu là Snap Sync, sẽ bỏ qua toàn bộ quá trình xác thực khối, tải trực tiếp dữ liệu trạng thái của checkpoint mới nhất và dữ liệu khối sau đó.
Nếu là Nút đã đồng bộ đến trạng thái mới nhất, thì sẽ liên tục lấy được khối mới nhất được sản xuất từ lớp đồng thuận thông qua Engine API, xác minh khối, sau đó thực thi tất cả các giao dịch trong khối bằng EVM để cập nhật cơ sở dữ liệu trạng thái, và ghi khối vào chuỗi địa phương.
Nếu nút đã đồng bộ đến trạng thái mới nhất và đã nhận quyền tạo khối từ lớp đồng thuận, nó sẽ thông qua Engine API để kích hoạt lớp thực thi tạo ra khối mới nhất, lớp thực thi sẽ lấy giao dịch từ hồ giao dịch và thực hiện, sau đó lắp ghép thành khối và truyền qua Engine API cho lớp đồng thuận, từ đó lớp đồng thuận sẽ phát tán khối đến mạng p2p của lớp đồng thuận.
03\Cấu trúc mã nguồn
Cấu trúc mã của go-ethereum rất lớn, nhưng nhiều mã trong đó thuộc về mã hỗ trợ và kiểm tra đơn vị. Khi nghiên cứu mã nguồn Geth, chỉ cần chú ý đến việc triển khai cốt lõi của giao thức, các chức năng của các mô-đun như sau. Cần chú ý đặc biệt đến các mô-đun core, eth, ethdb, node, p2p, rlp, trie & triedb.
tài khoản：quản lý tài khoản Ethereum, bao gồm việc tạo cặp khóa công tư, xác minh chữ ký, phân nhánh địa chỉ, v.v.
beacon: Xử lý logic tương tác với chuỗi beacon Ethereum (Beacon Chain), hỗ trợ chức năng sau khi hợp nhất (The Merge) của đồng thuận chứng minh cổ phần (PoS)
build：kịch bản xây dựng và cấu hình biên dịch (như Dockerfile, hỗ trợ biên dịch đa nền tảng)
cmd：Công cụ dòng lệnh nhập, bao gồm nhiều lệnh con
Phổ biến: Các lớp tiện ích chung, chẳng hạn như xử lý byte, chuyển đổi định dạng địa chỉ và các hàm toán học
đồng thuận：định nghĩa động cơ đồng thuận, bao gồm trước đây là chứng minh công việc (Ethash) và chứng minh cổ phần đơn (Clique) cũng như động cơ Beacon.
Bảng điều khiển: Cung cấp bảng điều khiển JavaScript tương tác cho phép người dùng tương tác trực tiếp với các nút Ethereum thông qua dòng lệnh (ví dụ: gọi API Web3, quản lý tài khoản, truy vấn dữ liệu blockchain)
cốt lõi: Logic cốt lõi của blockchain, xử lý việc quản lý vòng đời của các khối / giao dịch, máy trạng thái, tính toán khí, v.v
crypto: Triển khai thuật toán mã hóa, bao gồm đường cong elip (secp256k1), băm (Keccak-256), xác thực chữ ký
docs：Tài liệu (như tiêu chuẩn thiết kế, mô tả API)
ETH: Việc triển khai hoàn chỉnh giao thức mạng Ethereum, bao gồm các dịch vụ nút, đồng bộ hóa khối (như đồng bộ hóa nhanh, chế độ lưu trữ), phát sóng giao dịch, v.v
ethclient：Thư viện client Ethereum, bao bọc giao diện JSON-RPC, cung cấp cho các nhà phát triển Go tương tác với các Nút Ethereum (như truy vấn khối, gửi giao dịch, triển khai hợp đồng)
ethdb: lớp trừu tượng cơ sở dữ liệu, hỗ trợ LevelDB, Pebble, cơ sở dữ liệu trong bộ nhớ, lưu trữ dữ liệu blockchain (khối, trạng thái, giao dịch)
ethstats: Thu thập và báo cáo trạng thái hoạt động của Nút đến dịch vụ thống kê, dùng để theo dõi tình trạng sức khỏe của mạng.
event：Thực hiện cơ chế đăng ký và phát hành sự kiện, hỗ trợ giao tiếp bất đồng bộ giữa các mô-đun bên trong Nút (như việc khối mới đến, cập nhật hồ bơi giao dịch)
graphql: Cung cấp giao diện GraphQL để hỗ trợ các truy vấn phức tạp (thay thế một số hàm JSON-RPC)
internal：Công cụ nội bộ hoặc mã giới hạn truy cập bên ngoài
log：Hệ thống nhật ký, hỗ trợ xuất nhật ký phân cấp, ghi lại nhật ký ngữ cảnh
mertrics：thu thập chỉ số hiệu suất (hỗ trợ Prometheus)
miner：Logic liên quan đến việc khai thác, tạo khối mới và đóng gói giao dịch (trong bối cảnh PoW)
Nút：Quản lý dịch vụ nút, tích hợp khởi động và cấu hình các mô-đun p2p, RPC, cơ sở dữ liệu và các mô-đun khác.
p2p：Giao thức mạng điểm đến điểm, hỗ trợ phát hiện Nút, truyền dữ liệu, giao tiếp mã hóa
params：Định nghĩa các tham số mạng Ethereum (mạng chính, mạng thử nghiệm, cấu hình khối khởi đầu)
rlp：Triển khai giao thức tuần tự hóa dữ liệu đặc biệt cho Ethereum RLP (Recursive Length Prefix), dùng để mã hóa/giải mã các cấu trúc dữ liệu như khối, giao dịch, v.v.
rpc: Triển khai giao diện JSON-RPC và IPC, cung cấp cho các chương trình bên ngoài tương tác với Nút.
signer：Quản lý chữ ký giao dịch (tích hợp ví phần cứng)
tests：kiểm tra tích hợp và kiểm tra trạng thái, xác minh tính tương thích của giao thức
trie & triedb：Triệu Merkel Patricia (Merkle Patricia Trie) được triển khai để lưu trữ và quản lý trạng thái tài khoản, lưu trữ hợp đồng một cách hiệu quả.
04\Phân chia mô-đun lớp thực thi
Có hai hình thức truy cập Geth Nút từ bên ngoài, một là thông qua RPC, và một là thông qua Console. RPC phù hợp để mở cho người dùng bên ngoài sử dụng, trong khi Console phù hợp cho quản trị viên của nút sử dụng. Nhưng dù là thông qua RPC hay Console, đều sử dụng các khả năng đã được đóng gói sẵn bên trong, những khả năng này được xây dựng theo cách phân lớp.
Lớp ngoài cùng chính là API dùng cho việc truy cập các khả năng của các Nút từ bên ngoài, Engine API dùng cho việc giao tiếp giữa lớp thực thi và lớp đồng thuận, Eth API dùng cho người dùng hoặc chương trình bên ngoài gửi giao dịch, lấy thông tin khối, Net API dùng để lấy trạng thái của mạng p2p, v.v. Ví dụ, nếu người dùng gửi một giao dịch qua API, thì giao dịch đó cuối cùng sẽ được nộp vào hồ giao dịch, qua hồ giao dịch để quản lý. Hơn nữa, nếu người dùng cần lấy dữ liệu một khối, thì cần gọi khả năng của cơ sở dữ liệu để lấy khối tương ứng.
Ở tầng tiếp theo của API là việc thực hiện các chức năng cốt lõi, bao gồm hồ giao dịch, đóng gói giao dịch, sản xuất khối, đồng bộ khối và trạng thái, v.v. Những chức năng này cần phải dựa vào khả năng ở tầng thấp hơn, chẳng hạn như hồ giao dịch, đồng bộ khối và trạng thái cần phụ thuộc vào khả năng mạng p2p, việc tạo khối và các khối được đồng bộ từ các Nút khác cần phải được xác thực trước khi ghi vào cơ sở dữ liệu địa phương, và điều này cần phụ thuộc vào khả năng EVM và lưu trữ dữ liệu.
Cấu trúc Ethereum trong eth/backend.go là sự trừu tượng của toàn bộ giao thức Ethereum, cơ bản bao gồm các thành phần chính trong Ethereum, nhưng EVM là một ngoại lệ, nó sẽ được khởi tạo mỗi khi xử lý giao dịch, không cần thiết phải khởi tạo cùng với toàn bộ Nút. Thuật ngữ Ethereum trong phần dưới đây đều chỉ đến cấu trúc này:
nhập cấu trúc Ethereum { // Cấu hình Ethereum, bao gồm cấu hình chuỗi *ethconfig. Cấu hình // Nhóm giao dịch, sau khi giao dịch của người dùng được gửi, hãy chuyển đến nhóm giao dịch txPool *txpool. TxPool // Được sử dụng để theo dõi và quản lý các giao dịch địa phương localTxTracker *locals. TxTracker // Cấu trúc blockchain blockchain *core. BlockChain // là thành phần cốt lõi của lớp mạng của nút Ethereum, chịu trách nhiệm xử lý tất cả các giao tiếp với các nút khác, bao gồm đồng bộ hóa khối, phát và nhận giao dịch, cũng như quản lý trình xử lý kết nối nút ngang hàng // chịu trách nhiệm khám phá nút và quản lý nguồn nút discmix *enode. FairMix // Chịu trách nhiệm lưu trữ liên tục chuỗi dữ liệu blockchainDb ethdb. Cơ sở dữ liệu // Chịu trách nhiệm xử lý việc xuất bản và đăng ký các sự kiện nội bộ khác nhau cho eventMux *event. TypeMux // Đồng thuận động cơ. Công cụ // Quản lý tài khoản người dùng và khóa accountManager * tài khoản. Quản lý // Quản lý bộ lọc nhật ký và bộ lọc chunkMaps *filtermaps. FilterMaps // Kênh để tắt bộ lọc một cách an toànBản đồ bộ lọc, đảm bảo rằng tài nguyên được dọn dẹp chính xác khi các nút được tắt gầnFilterMaps chan chan struct{} // Cung cấp hỗ trợ phụ trợ cho API RPC APIBackend *EthAPIBackend // Trong PoS, làm việc với công cụ đồng thuận để xác thực trình khai thác khối * thợ mỏ. Người khai thác // Giá gas thấp nhất được nút chấp nhận là gasPrice * lớn. Int // ID mạng networkID uint64 // Cung cấp các dịch vụ RPC liên quan đến mạng, cho phép truy vấn trạng thái mạng thông qua RPC netRPCService *ethapi. NetAPI // Quản lý kết nối mạng P2P, xử lý phát hiện nút và thiết lập kết nối, đồng thời cung cấp các chức năng truyền tải mạng lớp nền p2pServer *p2p. Máy chủ // Bảo vệ quyền truy cập đồng thời vào đồng bộ hóa khóa các trường có thể thay đổi. RWMutex // Theo dõi xem nút có ngừng hoạt động một cách duyên dáng hay không và giúp khôi phục shutdownTracker sau khi tắt máy bất thường *shutdowncheck. ShutdownTracker }
Nút
Trong Node ở node/node.go là một cấu trúc dữ liệu cốt lõi khác, nó hoạt động như một container, chịu trách nhiệm quản lý và phối hợp các dịch vụ khác nhau. Trong cấu trúc dưới đây, cần chú ý đến trường lifecycles, Lifecycle được sử dụng để quản lý vòng đời của các chức năng nội bộ. Ví dụ, trừu tượng Ethereum ở trên cần phụ thuộc vào Node để có thể khởi động và được đăng ký trong lifecycles. Điều này cho phép tách biệt các chức năng cụ thể với trừu tượng của nút, nâng cao khả năng mở rộng của toàn bộ kiến trúc, Node này cần được phân biệt với Node trong devp2p.
gõ Node struct { eventmux *event. Cấu hình TypeMux *Config // Quản lý tài khoản, chịu trách nhiệm quản lý ví và tài khoản accman * tài khoản. Nhật ký quản lý. Logger keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // p2p network instance server *p2p. Máy chủ startStopLock đồng bộ hóa. Mutex // Theo dõi trạng thái vòng đời nút (khởi tạo, chạy, đóng) trạng thái int lock sync. Mutex // Tất cả các phụ trợ, dịch vụ và vòng đời dịch vụ phụ trợ đã đăng ký []Vòng đời // Danh sách các API rpcAPI hiện có sẵn []rpc. API // Các phương thức truy cập khác nhau cho RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Ánh xạ cơ sở dữ liệu máy chủ[*closeTrackingDB]struct{} }
Nếu chúng ta nhìn vào lớp thực thi của Ethereum từ một chiều trừu tượng, Ethereum, với tư cách là một máy tính thế giới, cần bao gồm ba phần, mạng, tính toán và lưu trữ, thì các thành phần tương ứng với ba phần này trong lớp thực thi Ethereum là:
Mạng: devp2p
Tính toán: EVM
Lưu trữ: ethdb
devp2p
Ethereum về bản chất vẫn là một hệ thống phân tán, mỗi Nút được kết nối với các Nút khác thông qua mạng p2p. Việc triển khai giao thức mạng p2p trong Ethereum chính là devp2p.
devp2p có hai chức năng cốt lõi, một là Nút phát hiện, cho phép các Nút thiết lập liên lạc với các Nút khác khi kết nối vào mạng; chức năng còn lại là dịch vụ truyền dữ liệu, sau khi thiết lập liên lạc với các Nút khác, có thể tiến hành trao đổi dữ liệu.
Cấu trúc Node trong p2p/enode/node.go đại diện cho một Nút trong mạng p2p, trong đó cấu trúc enr.Record lưu trữ các cặp khóa-giá trị thông tin chi tiết về Nút, bao gồm thông tin danh tính (thuật toán ký được sử dụng cho danh tính Nút, khóa công khai), thông tin mạng (địa chỉ IP, số cổng), thông tin giao thức được hỗ trợ (như hỗ trợ giao thức eth/68 và snap) và các thông tin tùy chỉnh khác, các thông tin này được mã hóa bằng cách sử dụng RLP, quy định cụ thể được định nghĩa trong eip-778:
type Node struct { // Nút ghi lại, bao gồm các thuộc tính khác nhau của nút r enr.Record // Định danh duy nhất của nút, độ dài 32 byte id ID // hostname theo dõi tên DNS của nút hostname string // Địa chỉ IP của nút ip netip.Addr // Cổng UDP udp uint16 // Cổng TCP tcp uint16 }// enr.Recordtype Record struct { // Số sê-ri seq uint64 // Chữ ký signature []byte // Bản ghi đã được mã hóa RLP raw []byte // Danh sách các cặp khóa giá trị đã được sắp xếp pairs []pair }
Cấu trúc Table trong p2p/discover/table.go là cấu trúc dữ liệu cốt lõi của giao thức phát hiện nút do devp2p triển khai, nó thực hiện bảng băm phân tán tương tự như Kademlia, được sử dụng để duy trì và quản lý thông tin về các nút trong mạng.
printf("type Table struct { mutex sync.Mutex // Theo khoảng cách chỉ mục các Nút đã biết buckets [nBuckets]*bucket // Nút hướng dẫn nursery []*enode.Node rand reseedingRandom ips netutil.DistinctNetSet revalidation tableRevalidation // Cơ sở dữ liệu của các Nút đã biết db *enode.DB net transport cfg Config log log.Logger // Xử lý có chu kỳ các sự kiện khác nhau trong mạng refreshReq chan chan struct{} revalResponseCh chan revalidationResponse addNodeCh chan addNodeOp addNodeHandled chan bool trackRequestCh chan trackRequestOp initDone chan struct{} closeReq chan struct{} closed chan struct{} // Giao diện thêm và xóa Nút nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(*bucket, *tableNode)} world!");
ethdb
ethdb hoàn thành việc trừu tượng hóa lưu trữ dữ liệu Ethereum, cung cấp giao diện lưu trữ thống nhất, cơ sở dữ liệu cụ thể ở dưới có thể là leveldb, cũng có thể là pebble hoặc các cơ sở dữ liệu khác. Có thể có nhiều mở rộng, miễn là giữ cho mặt giao diện thống nhất.
Một số dữ liệu (chẳng hạn như dữ liệu khối) có thể được đọc và ghi trực tiếp vào cơ sở dữ liệu cơ bản thông qua giao diện ethdb và các giao diện lưu trữ dữ liệu khác dựa trên ethdb, ví dụ, một phần lớn dữ liệu trong cơ sở dữ liệu là dữ liệu trạng thái, sẽ được tổ chức thành cấu trúc MPT và việc triển khai tương ứng trong Geth là trie Để quản lý dữ liệu này và trạng thái trung gian, và cuối cùng duy trì nó thông qua ETHDB.
Giao diện xác định khả năng đọc và ghi của cơ sở dữ liệu cơ bản trong ethdb / database.go không bao gồm một triển khai cụ thể, sẽ được thực hiện bởi chính các cơ sở dữ liệu khác nhau. Ví dụ: cơ sở dữ liệu leveldb hoặc pebble. Hai lớp giao diện đọc / ghi dữ liệu được xác định trong cơ sở dữ liệu, trong đó giao diện KeyValueStore được sử dụng để lưu trữ dữ liệu hoạt động và thường xuyên thay đổi, chẳng hạn như khối, trạng thái mới nhất, v.v. AncientStore được sử dụng để xử lý dữ liệu đoạn lịch sử, hiếm khi thay đổi sau khi được viết.
// Giao diện cấp cao của cơ sở dữ liệutype Database interface { KeyValueStore Nút}// Giao diện đọc và ghi dữ liệu KVtype KeyValueStore interface { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee Compacter io.Closer}// Giao diện đọc và ghi dữ liệu cũtype AncientStore interface { AncientReader AncientWriter AncientStater io.Closer}
EVM
EVM là hàm chuyển đổi trạng thái của máy trạng thái Ethereum, mọi cập nhật dữ liệu trạng thái chỉ có thể được thực hiện thông qua EVM, mạng p2p có thể nhận được thông tin giao dịch và khối, những thông tin này sau khi được EVM xử lý sẽ trở thành một phần của cơ sở dữ liệu trạng thái. EVM che giấu sự khác biệt của phần cứng dưới lớp, cho phép chương trình thực thi trên các EVM của các nền tảng khác nhau đạt được kết quả nhất quán. Đây là một cách thiết kế rất trưởng thành, JVM trong ngôn ngữ Java cũng có thiết kế tương tự.
Cấu trúc EVM trong core / vm / evm.go xác định cấu trúc tổng thể và các phụ thuộc của EVM, bao gồm bối cảnh thực thi, phụ thuộc cơ sở dữ liệu trạng thái, v.v.; Cấu trúc EVMInterpreter trong core/vm/interpreter.go định nghĩa việc triển khai trình thông dịch và chịu trách nhiệm thực thi mã byte EVM; Cấu trúc Hợp đồng trong core/vm/contract.go gói gọn các tham số cụ thể của lệnh gọi hợp đồng, bao gồm người gọi, mã hợp đồng, đầu vào, v.v. và xác định tất cả các opcode hiện tại trong core/vm/opcodes.go:
EVMtype EVM struct { // Block context, chứa thông tin liên quan đến block Context BlockContext // Transaction context, chứa thông tin liên quan đến giao dịch TxContext // State database, được sử dụng để truy cập và sửa đổi trạng thái tài khoản StateDB StateDB // Current call depth int // Tham số cấu hình chuỗi chainConfig *params. ChainConfig chainRules params. Quy tắc // Cấu hình EVM Cấu hình // Trình thông dịch thông dịch bytecode *EVMInterpreter // Hủy bỏ cờ thực thi hủy bỏ nguyên tử. Bool callGasTemp uint64 // precompiles map[common. Địa chỉ]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // Trỏ đến phiên bản EVM mà nó thuộc về evm *EVM // Opcode Jump Table table *JumpTable // Keccak256 hasher instance, share hasher crypto giữa các opcode. KeccakState // Keccak256 hash kết quả đệm hasherBuf phổ biến. Hash // Cho dù đó là chế độ chỉ đọc, sửa đổi trạng thái không được phép ở chế độ chỉ đọc readOnly bool // Dữ liệu trả về của CALL cuối cùng được sử dụng để tái sử dụng tiếp theo returnData []byte }type Cấu trúc hợp đồng { // người gọi địa chỉ của người gọi chung. Địa chỉ // Địa chỉ hợp đồng địa chỉ chung. Địa chỉ jumpdests map[common. Hash]phân tích bitvec bitvec // Mã bytecode hợp đồng []byte // Mã băm mã CodeHash phổ biến. Hash // Đầu vào cuộc gọi []byte // Có nên triển khai IsDeployment bool cho hợp đồng // Có nên gọi IsSystemCall bool // Có sẵn gas gas uint64 // Số lượng ETH gắn liền với giá trị cuộc gọi *uint256. Int }
Các mô-đun khác được thực hiện
Chức năng của lớp thực thi được thực hiện thông qua cách phân lớp, các mô-đun và chức năng khác đều được xây dựng dựa trên ba thành phần cốt lõi này. Dưới đây là một vài mô-đun cốt lõi.
Có các triển khai của các giao thức mạng p2p hiện tại của Ethereum dưới eth/protocols. Có các giao thức con eth/68 và snap, tất cả các giao thức con này đều được xây dựng trên devp2p.
eth/68 là giao thức cốt lõi của Ethereum, tên giao thức là eth, 68 là số phiên bản của nó, và trên cơ sở giao thức này còn thực hiện các chức năng như hồ giao dịch (TxPool), đồng bộ khối (Downloader) và đồng bộ giao dịch (Fetcher). Giao thức snap được sử dụng để đồng bộ nhanh chóng các khối và dữ liệu trạng thái khi nút mới tham gia vào mạng, có thể giảm đáng kể thời gian khởi động của nút mới.
ethdb cung cấp khả năng đọc và ghi cho cơ sở dữ liệu nền tảng, do trong giao thức Ethereum có nhiều cấu trúc dữ liệu phức tạp, nên không thể quản lý dữ liệu này trực tiếp thông qua ethdb, vì vậy đã triển khai rawdb và statedb trên ethdb để quản lý dữ liệu khối và trạng thái một cách riêng biệt.
EVM thì xuyên suốt tất cả các quy trình chính, bất kể là xây dựng khối hay xác thực khối, đều cần thực hiện giao dịch bằng EVM.
05\Geth Nút khởi động quy trình
Geth khởi động sẽ được chia thành hai giai đoạn, giai đoạn đầu tiên sẽ khởi tạo các thành phần và tài nguyên cần thiết để khởi động Nút, giai đoạn thứ hai Nút sẽ chính thức khởi động và sau đó cung cấp dịch vụ ra bên ngoài.
Nút khởi tạo
Khi khởi động một nút geth, sẽ liên quan đến đoạn mã sau:
Các mô-đun được khởi tạo như sau:
cmd/geth/main.go：geth Nút khởi động vào
cmd/geth/config.go（makeFullNode）：Tải cấu hình, khởi tạo Nút
Nút/node.go: Khởi tạo container lõi của nút Ethereum
node.rpcstack.go：khởi tạo mô-đun RPC
accounts.manager.go：khởi tạo accountManager
eth/backend.go: Khởi tạo phiên bản Ethereum
Nút/node.go OpenDatabaseWithFreezer：khởi tạo chaindb
eth/ethconfig/config.go: Khởi tạo thể hiện động cơ đồng thuận (động cơ đồng thuận ở đây không thực sự tham gia vào đồng thuận, chỉ xác minh kết quả của lớp đồng thuận và xử lý yêu cầu rút tiền của validator)
core/blockchain.go：khởi tạo blockchain
core/filterMaps.go：khởi tạo filtermaps
core/txpool/blobpool/blobpool.go：khởi tạo hồ bơi giao dịch blob
core/txpool/legacypool/legacypool.go: khởi tạo bể giao dịch thông thường
cord/txpool/locals/tx_tracker.go：Theo dõi giao dịch cục bộ (cần cấu hình để bật theo dõi giao dịch cục bộ, giao dịch cục bộ sẽ được xử lý với độ ưu tiên cao hơn)
eth/handler.go: Khởi tạo phiên bản Handler của giao thức
miner/miner.go: Mô-đun đóng gói giao dịch được khởi tạo (Mô-đun khai thác nguyên bản)
eth/api_backend.go：Khởi tạo dịch vụ RPC
eth/gasprice/gasprice.go: Khởi tạo dịch vụ truy vấn giá gas
internal/ethapi/api.go：khởi tạo API RPC mạng P2P
Nút/node.go(Đăng kýAPIs)：Đăng ký RPC API
Nút/node.go(RegisterProtocols)：đăng ký các Ptotocols p2p
Nút/node.go(Đăng ký vòng đời): Đăng ký vòng đời của các thành phần khác nhau
cmd/utils/flags.go(Đăng ký Filter API RPC)：Đăng ký Filter RPC API
cmd/utils/flags.go(Đăng ký Dịch vụ GraphQL)：Đăng ký API RPC GraphQL (nếu đã được cấu hình)
cmd/utils/flags.go(Đăng ký dịch vụ EthStats RPC API) (nếu đã được cấu hình)
eth/catalyst/api.go：Đăng ký Engine API
Việc khởi tạo Nút sẽ được thực hiện trong makeFullNode của cmd/geth/config.go, chú trọng khởi tạo ba mô-đun sau.
Trong bước đầu tiên, sẽ khởi tạo cấu trúc Node trong file node/node.go, tức là toàn bộ container của nút, tất cả các chức năng cần phải chạy trong container này. Bước thứ hai sẽ khởi tạo cấu trúc Ethereum, trong đó bao gồm việc triển khai các chức năng cốt lõi của Ethereum, Etherereum cũng cần được đăng ký vào Node. Bước thứ ba là đăng ký Engine API vào Node.
Trong đó, việc khởi tạo Nút chính là tạo ra một phiên bản Nút, sau đó khởi tạo máy chủ p2p, quản lý tài khoản và các cổng giao thức http được công khai ra bên ngoài.
Ethereum phức tạp hơn nhiều để khởi tạo và hầu hết các chức năng cốt lõi được khởi tạo ở đây. Đầu tiên, ethdb sẽ được khởi tạo và cấu hình chuỗi sẽ được tải từ bộ lưu trữ, sau đó công cụ đồng thuận sẽ được tạo, trong đó công cụ đồng thuận sẽ không thực hiện các hoạt động đồng thuận mà sẽ chỉ xác minh kết quả được trả về bởi lớp đồng thuận và nếu yêu cầu rút tiền xảy ra trong lớp đồng thuận, hoạt động rút tiền thực tế cũng sẽ được hoàn thành ở đây. Sau đó khởi tạo cấu trúc Block Chain và nhóm giao dịch.
Sau khi hoàn thành tất cả những điều này, handler sẽ được khởi tạo, handler là điểm vào xử lý cho tất cả các yêu cầu mạng p2p, bao gồm đồng bộ giao dịch, tải xuống khối, v.v., là thành phần quan trọng để Ethereum thực hiện hoạt động phi tập trung. Sau khi hoàn thành những điều này, một số giao thức con được triển khai dựa trên devp2p, chẳng hạn như eth/68, snap, sẽ được đăng ký vào container Node, cuối cùng Ethereum sẽ được đăng ký như một lifecycle trong container Node, việc khởi tạo Ethereum hoàn tất.
Cuối cùng, việc khởi tạo Engine API tương đối đơn giản, chỉ cần đăng ký Engine API vào Nút. Đến đây, việc khởi tạo nút đã hoàn tất.
Nút khởi động
Sau khi hoàn thành việc khởi tạo Nút, bạn cần khởi động Nút. Quy trình khởi động Nút tương đối đơn giản, chỉ cần khởi động tất cả các dịch vụ RPC đã đăng ký và Lifecycle, thì toàn bộ Nút có thể cung cấp dịch vụ ra bên ngoài.
06\tóm tắt
Trước khi hiểu được việc triển khai lớp thực thi của Ethereum, cần phải có sự hiểu biết toàn diện về Ethereum, có thể được xem như một máy trạng thái hướng giao dịch, trong đó lớp thực thi chịu trách nhiệm thực hiện các giao dịch và thay đổi trạng thái, và lớp đồng thuận chịu trách nhiệm điều khiển lớp thực thi, bao gồm làm cho lớp thực thi tạo ra các khối, quyết định thứ tự giao dịch, bỏ phiếu cho các khối và tạo các khối cuối cùng. Vì máy trạng thái này được phân cấp, nó cần giao tiếp với các nút khác thông qua mạng P2P để cùng duy trì tính nhất quán của dữ liệu trạng thái.
Tầng thực thi không chịu trách nhiệm quyết định thứ tự giao dịch, chỉ chịu trách nhiệm thực hiện giao dịch và ghi lại sự thay đổi trạng thái sau khi giao dịch được thực hiện. Có hai hình thức ghi lại ở đây, một là ghi lại tất cả sự thay đổi trạng thái dưới dạng khối, hình thức còn lại là ghi lại trạng thái hiện tại trong cơ sở dữ liệu. Cùng lúc, tầng thực thi cũng là điểm vào giao dịch, thông qua hồ giao dịch để lưu trữ các giao dịch chưa được đóng gói vào khối. Nếu các Nút khác cần lấy dữ liệu khối, trạng thái và giao dịch, tầng thực thi sẽ gửi những thông tin này qua mạng p2p.
Đối với lớp thực thi, có ba mô-đun cốt lõi: tính toán, lưu trữ và mạng. Tính toán tương ứng với việc thực hiện EVM, lưu trữ tương ứng với việc thực hiện ethdb, mạng tương ứng với việc thực hiện devp2p. Sau khi có được cái nhìn tổng thể như vậy, bạn có thể đi sâu vào việc hiểu từng mô-đun con mà không bị lạc trong các chi tiết cụ thể.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Khách hàng chính của Ethereum: Kiến trúc tổng thể của Geth
Bài viết này là bài đầu tiên trong chuỗi mã nguồn Geth, qua chuỗi này, chúng ta sẽ xây dựng một khung nghiên cứu về việc thực hiện Geth, người phát triển có thể dựa trên khung này để nghiên cứu sâu về những phần mà họ quan tâm. Chuỗi này có tổng cộng sáu bài viết, trong bài đầu tiên, sẽ nghiên cứu cấu trúc thiết kế của khách hàng Geth ở tầng thực thi và quy trình khởi động nút Geth. Mã Geth được cập nhật rất nhanh, mã mà bạn thấy sau này có thể khác nhau, nhưng thiết kế tổng thể vẫn tương đối nhất quán, mã mới cũng có thể được đọc theo cách tương tự.
01\Khách hàng Ethereum
Trước khi thực hiện nâng cấp The Merge, Ethereum chỉ có một khách hàng, khách hàng này chịu trách nhiệm thực hiện giao dịch và cũng sẽ chịu trách nhiệm về sự đồng thuận của blockchain, đảm bảo blockchain tạo ra các khối mới theo một thứ tự nhất định. Sau khi nâng cấp The Merge, khách hàng Ethereum đã được chia thành tầng thực thi và tầng đồng thuận, tầng thực thi chịu trách nhiệm thực hiện giao dịch, duy trì trạng thái và dữ liệu, trong khi tầng đồng thuận chịu trách nhiệm thực hiện chức năng đồng thuận, tầng thực thi và tầng đồng thuận giao tiếp với nhau thông qua API. Tầng thực thi và tầng đồng thuận có các quy định riêng, khách hàng có thể sử dụng các ngôn ngữ khác nhau để thực hiện, nhưng phải tuân theo các quy định tương ứng, trong đó Geth là một trong những cách thực hiện của khách hàng tầng thực thi. Hiện tại, các khách hàng tầng thực thi và tầng đồng thuận phổ biến có các cách thực hiện như sau:
Thực thi
Tầng đồng thuận
02\Giới thiệu về lớp thực thi
Có thể coi lớp thực thi Ethereum như một máy trạng thái được điều khiển bởi giao dịch, chức năng cơ bản nhất của lớp thực thi là cập nhật dữ liệu trạng thái thông qua việc thực thi giao dịch bằng EVM. Ngoài việc thực thi giao dịch, còn có các chức năng khác như lưu trữ và xác minh khối và dữ liệu trạng thái, chạy mạng p2p và duy trì hồ giao dịch.
Giao dịch được người dùng (hoặc chương trình) tạo ra theo định dạng được định nghĩa bởi tiêu chuẩn của lớp thực thi Ethereum, người dùng cần ký giao dịch. Nếu giao dịch hợp lệ (Nonce liên tiếp, chữ ký đúng, phí gas đủ, logic nghiệp vụ đúng), thì giao dịch cuối cùng sẽ được EVM thực thi, từ đó cập nhật trạng thái của mạng Ethereum. Ở đây, trạng thái chỉ tập hợp các cấu trúc dữ liệu, dữ liệu và cơ sở dữ liệu, bao gồm địa chỉ tài khoản bên ngoài, địa chỉ hợp đồng, số dư địa chỉ cũng như mã và dữ liệu.
Lớp thực thi chịu trách nhiệm thực hiện giao dịch và duy trì trạng thái sau khi thực hiện giao dịch, trong khi lớp đồng thuận chịu trách nhiệm chọn giao dịch nào để thực hiện. EVM là hàm chuyển đổi trạng thái trong máy trạng thái này, đầu vào của hàm có thể đến từ nhiều nguồn khác nhau, có thể đến từ thông tin khối mới nhất do lớp đồng thuận cung cấp hoặc có thể đến từ khối được tải xuống từ mạng p2p.
Lớp đồng thuận và lớp thực thi giao tiếp qua Engine API, đây là cách giao tiếp duy nhất giữa lớp thực thi và lớp đồng thuận. Nếu lớp đồng thuận có quyền tạo khối, nó sẽ thông qua Engine API để cho lớp thực thi tạo ra khối mới; nếu không có quyền tạo khối, nó sẽ đồng bộ khối mới nhất để lớp thực thi xác minh và thực hiện, từ đó duy trì sự đồng thuận với toàn bộ mạng Ethereum.
Lớp thực thi về mặt logic có thể được chia thành 6 phần:
Hình dưới đây hiển thị quy trình chính của lớp thực thi, cũng như chức năng của từng phần:
Đối với lớp thực thi (tạm thời chỉ thảo luận về Full Node), có ba quy trình quan trọng:
03\Cấu trúc mã nguồn
Cấu trúc mã của go-ethereum rất lớn, nhưng nhiều mã trong đó thuộc về mã hỗ trợ và kiểm tra đơn vị. Khi nghiên cứu mã nguồn Geth, chỉ cần chú ý đến việc triển khai cốt lõi của giao thức, các chức năng của các mô-đun như sau. Cần chú ý đặc biệt đến các mô-đun core, eth, ethdb, node, p2p, rlp, trie & triedb.
04\Phân chia mô-đun lớp thực thi
Có hai hình thức truy cập Geth Nút từ bên ngoài, một là thông qua RPC, và một là thông qua Console. RPC phù hợp để mở cho người dùng bên ngoài sử dụng, trong khi Console phù hợp cho quản trị viên của nút sử dụng. Nhưng dù là thông qua RPC hay Console, đều sử dụng các khả năng đã được đóng gói sẵn bên trong, những khả năng này được xây dựng theo cách phân lớp.
Lớp ngoài cùng chính là API dùng cho việc truy cập các khả năng của các Nút từ bên ngoài, Engine API dùng cho việc giao tiếp giữa lớp thực thi và lớp đồng thuận, Eth API dùng cho người dùng hoặc chương trình bên ngoài gửi giao dịch, lấy thông tin khối, Net API dùng để lấy trạng thái của mạng p2p, v.v. Ví dụ, nếu người dùng gửi một giao dịch qua API, thì giao dịch đó cuối cùng sẽ được nộp vào hồ giao dịch, qua hồ giao dịch để quản lý. Hơn nữa, nếu người dùng cần lấy dữ liệu một khối, thì cần gọi khả năng của cơ sở dữ liệu để lấy khối tương ứng.
Ở tầng tiếp theo của API là việc thực hiện các chức năng cốt lõi, bao gồm hồ giao dịch, đóng gói giao dịch, sản xuất khối, đồng bộ khối và trạng thái, v.v. Những chức năng này cần phải dựa vào khả năng ở tầng thấp hơn, chẳng hạn như hồ giao dịch, đồng bộ khối và trạng thái cần phụ thuộc vào khả năng mạng p2p, việc tạo khối và các khối được đồng bộ từ các Nút khác cần phải được xác thực trước khi ghi vào cơ sở dữ liệu địa phương, và điều này cần phụ thuộc vào khả năng EVM và lưu trữ dữ liệu.
! Máy khách chính Ethereum: Kiến trúc tổng thể Geth
Cấu trúc dữ liệu cốt lõi của lớp thực thi
Ethereum
Cấu trúc Ethereum trong eth/backend.go là sự trừu tượng của toàn bộ giao thức Ethereum, cơ bản bao gồm các thành phần chính trong Ethereum, nhưng EVM là một ngoại lệ, nó sẽ được khởi tạo mỗi khi xử lý giao dịch, không cần thiết phải khởi tạo cùng với toàn bộ Nút. Thuật ngữ Ethereum trong phần dưới đây đều chỉ đến cấu trúc này:
nhập cấu trúc Ethereum { // Cấu hình Ethereum, bao gồm cấu hình chuỗi *ethconfig. Cấu hình // Nhóm giao dịch, sau khi giao dịch của người dùng được gửi, hãy chuyển đến nhóm giao dịch txPool *txpool. TxPool // Được sử dụng để theo dõi và quản lý các giao dịch địa phương localTxTracker *locals. TxTracker // Cấu trúc blockchain blockchain *core. BlockChain // là thành phần cốt lõi của lớp mạng của nút Ethereum, chịu trách nhiệm xử lý tất cả các giao tiếp với các nút khác, bao gồm đồng bộ hóa khối, phát và nhận giao dịch, cũng như quản lý trình xử lý kết nối nút ngang hàng // chịu trách nhiệm khám phá nút và quản lý nguồn nút discmix *enode. FairMix // Chịu trách nhiệm lưu trữ liên tục chuỗi dữ liệu blockchainDb ethdb. Cơ sở dữ liệu // Chịu trách nhiệm xử lý việc xuất bản và đăng ký các sự kiện nội bộ khác nhau cho eventMux *event. TypeMux // Đồng thuận động cơ. Công cụ // Quản lý tài khoản người dùng và khóa accountManager * tài khoản. Quản lý // Quản lý bộ lọc nhật ký và bộ lọc chunkMaps *filtermaps. FilterMaps // Kênh để tắt bộ lọc một cách an toànBản đồ bộ lọc, đảm bảo rằng tài nguyên được dọn dẹp chính xác khi các nút được tắt gầnFilterMaps chan chan struct{} // Cung cấp hỗ trợ phụ trợ cho API RPC APIBackend *EthAPIBackend // Trong PoS, làm việc với công cụ đồng thuận để xác thực trình khai thác khối * thợ mỏ. Người khai thác // Giá gas thấp nhất được nút chấp nhận là gasPrice * lớn. Int // ID mạng networkID uint64 // Cung cấp các dịch vụ RPC liên quan đến mạng, cho phép truy vấn trạng thái mạng thông qua RPC netRPCService *ethapi. NetAPI // Quản lý kết nối mạng P2P, xử lý phát hiện nút và thiết lập kết nối, đồng thời cung cấp các chức năng truyền tải mạng lớp nền p2pServer *p2p. Máy chủ // Bảo vệ quyền truy cập đồng thời vào đồng bộ hóa khóa các trường có thể thay đổi. RWMutex // Theo dõi xem nút có ngừng hoạt động một cách duyên dáng hay không và giúp khôi phục shutdownTracker sau khi tắt máy bất thường *shutdowncheck. ShutdownTracker }
Nút
Trong Node ở node/node.go là một cấu trúc dữ liệu cốt lõi khác, nó hoạt động như một container, chịu trách nhiệm quản lý và phối hợp các dịch vụ khác nhau. Trong cấu trúc dưới đây, cần chú ý đến trường lifecycles, Lifecycle được sử dụng để quản lý vòng đời của các chức năng nội bộ. Ví dụ, trừu tượng Ethereum ở trên cần phụ thuộc vào Node để có thể khởi động và được đăng ký trong lifecycles. Điều này cho phép tách biệt các chức năng cụ thể với trừu tượng của nút, nâng cao khả năng mở rộng của toàn bộ kiến trúc, Node này cần được phân biệt với Node trong devp2p.
gõ Node struct { eventmux *event. Cấu hình TypeMux *Config // Quản lý tài khoản, chịu trách nhiệm quản lý ví và tài khoản accman * tài khoản. Nhật ký quản lý. Logger keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // p2p network instance server *p2p. Máy chủ startStopLock đồng bộ hóa. Mutex // Theo dõi trạng thái vòng đời nút (khởi tạo, chạy, đóng) trạng thái int lock sync. Mutex // Tất cả các phụ trợ, dịch vụ và vòng đời dịch vụ phụ trợ đã đăng ký []Vòng đời // Danh sách các API rpcAPI hiện có sẵn []rpc. API // Các phương thức truy cập khác nhau cho RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Ánh xạ cơ sở dữ liệu máy chủ[*closeTrackingDB]struct{} }
Nếu chúng ta nhìn vào lớp thực thi của Ethereum từ một chiều trừu tượng, Ethereum, với tư cách là một máy tính thế giới, cần bao gồm ba phần, mạng, tính toán và lưu trữ, thì các thành phần tương ứng với ba phần này trong lớp thực thi Ethereum là:
devp2p
Ethereum về bản chất vẫn là một hệ thống phân tán, mỗi Nút được kết nối với các Nút khác thông qua mạng p2p. Việc triển khai giao thức mạng p2p trong Ethereum chính là devp2p.
devp2p có hai chức năng cốt lõi, một là Nút phát hiện, cho phép các Nút thiết lập liên lạc với các Nút khác khi kết nối vào mạng; chức năng còn lại là dịch vụ truyền dữ liệu, sau khi thiết lập liên lạc với các Nút khác, có thể tiến hành trao đổi dữ liệu.
Cấu trúc Node trong p2p/enode/node.go đại diện cho một Nút trong mạng p2p, trong đó cấu trúc enr.Record lưu trữ các cặp khóa-giá trị thông tin chi tiết về Nút, bao gồm thông tin danh tính (thuật toán ký được sử dụng cho danh tính Nút, khóa công khai), thông tin mạng (địa chỉ IP, số cổng), thông tin giao thức được hỗ trợ (như hỗ trợ giao thức eth/68 và snap) và các thông tin tùy chỉnh khác, các thông tin này được mã hóa bằng cách sử dụng RLP, quy định cụ thể được định nghĩa trong eip-778:
type Node struct { // Nút ghi lại, bao gồm các thuộc tính khác nhau của nút r enr.Record // Định danh duy nhất của nút, độ dài 32 byte id ID // hostname theo dõi tên DNS của nút hostname string // Địa chỉ IP của nút ip netip.Addr // Cổng UDP udp uint16 // Cổng TCP tcp uint16 }// enr.Recordtype Record struct { // Số sê-ri seq uint64 // Chữ ký signature []byte // Bản ghi đã được mã hóa RLP raw []byte // Danh sách các cặp khóa giá trị đã được sắp xếp pairs []pair }
Cấu trúc Table trong p2p/discover/table.go là cấu trúc dữ liệu cốt lõi của giao thức phát hiện nút do devp2p triển khai, nó thực hiện bảng băm phân tán tương tự như Kademlia, được sử dụng để duy trì và quản lý thông tin về các nút trong mạng.
printf("type Table struct { mutex sync.Mutex // Theo khoảng cách chỉ mục các Nút đã biết buckets [nBuckets]*bucket // Nút hướng dẫn nursery []*enode.Node rand reseedingRandom ips netutil.DistinctNetSet revalidation tableRevalidation // Cơ sở dữ liệu của các Nút đã biết db *enode.DB net transport cfg Config log log.Logger // Xử lý có chu kỳ các sự kiện khác nhau trong mạng refreshReq chan chan struct{} revalResponseCh chan revalidationResponse addNodeCh chan addNodeOp addNodeHandled chan bool trackRequestCh chan trackRequestOp initDone chan struct{} closeReq chan struct{} closed chan struct{} // Giao diện thêm và xóa Nút nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(*bucket, *tableNode)} world!");
ethdb
ethdb hoàn thành việc trừu tượng hóa lưu trữ dữ liệu Ethereum, cung cấp giao diện lưu trữ thống nhất, cơ sở dữ liệu cụ thể ở dưới có thể là leveldb, cũng có thể là pebble hoặc các cơ sở dữ liệu khác. Có thể có nhiều mở rộng, miễn là giữ cho mặt giao diện thống nhất.
Một số dữ liệu (chẳng hạn như dữ liệu khối) có thể được đọc và ghi trực tiếp vào cơ sở dữ liệu cơ bản thông qua giao diện ethdb và các giao diện lưu trữ dữ liệu khác dựa trên ethdb, ví dụ, một phần lớn dữ liệu trong cơ sở dữ liệu là dữ liệu trạng thái, sẽ được tổ chức thành cấu trúc MPT và việc triển khai tương ứng trong Geth là trie Để quản lý dữ liệu này và trạng thái trung gian, và cuối cùng duy trì nó thông qua ETHDB.
Giao diện xác định khả năng đọc và ghi của cơ sở dữ liệu cơ bản trong ethdb / database.go không bao gồm một triển khai cụ thể, sẽ được thực hiện bởi chính các cơ sở dữ liệu khác nhau. Ví dụ: cơ sở dữ liệu leveldb hoặc pebble. Hai lớp giao diện đọc / ghi dữ liệu được xác định trong cơ sở dữ liệu, trong đó giao diện KeyValueStore được sử dụng để lưu trữ dữ liệu hoạt động và thường xuyên thay đổi, chẳng hạn như khối, trạng thái mới nhất, v.v. AncientStore được sử dụng để xử lý dữ liệu đoạn lịch sử, hiếm khi thay đổi sau khi được viết.
// Giao diện cấp cao của cơ sở dữ liệutype Database interface { KeyValueStore Nút}// Giao diện đọc và ghi dữ liệu KVtype KeyValueStore interface { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee Compacter io.Closer}// Giao diện đọc và ghi dữ liệu cũtype AncientStore interface { AncientReader AncientWriter AncientStater io.Closer}
EVM
EVM là hàm chuyển đổi trạng thái của máy trạng thái Ethereum, mọi cập nhật dữ liệu trạng thái chỉ có thể được thực hiện thông qua EVM, mạng p2p có thể nhận được thông tin giao dịch và khối, những thông tin này sau khi được EVM xử lý sẽ trở thành một phần của cơ sở dữ liệu trạng thái. EVM che giấu sự khác biệt của phần cứng dưới lớp, cho phép chương trình thực thi trên các EVM của các nền tảng khác nhau đạt được kết quả nhất quán. Đây là một cách thiết kế rất trưởng thành, JVM trong ngôn ngữ Java cũng có thiết kế tương tự.
Cấu trúc EVM trong core / vm / evm.go xác định cấu trúc tổng thể và các phụ thuộc của EVM, bao gồm bối cảnh thực thi, phụ thuộc cơ sở dữ liệu trạng thái, v.v.; Cấu trúc EVMInterpreter trong core/vm/interpreter.go định nghĩa việc triển khai trình thông dịch và chịu trách nhiệm thực thi mã byte EVM; Cấu trúc Hợp đồng trong core/vm/contract.go gói gọn các tham số cụ thể của lệnh gọi hợp đồng, bao gồm người gọi, mã hợp đồng, đầu vào, v.v. và xác định tất cả các opcode hiện tại trong core/vm/opcodes.go:
EVMtype EVM struct { // Block context, chứa thông tin liên quan đến block Context BlockContext // Transaction context, chứa thông tin liên quan đến giao dịch TxContext // State database, được sử dụng để truy cập và sửa đổi trạng thái tài khoản StateDB StateDB // Current call depth int // Tham số cấu hình chuỗi chainConfig *params. ChainConfig chainRules params. Quy tắc // Cấu hình EVM Cấu hình // Trình thông dịch thông dịch bytecode *EVMInterpreter // Hủy bỏ cờ thực thi hủy bỏ nguyên tử. Bool callGasTemp uint64 // precompiles map[common. Địa chỉ]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // Trỏ đến phiên bản EVM mà nó thuộc về evm *EVM // Opcode Jump Table table *JumpTable // Keccak256 hasher instance, share hasher crypto giữa các opcode. KeccakState // Keccak256 hash kết quả đệm hasherBuf phổ biến. Hash // Cho dù đó là chế độ chỉ đọc, sửa đổi trạng thái không được phép ở chế độ chỉ đọc readOnly bool // Dữ liệu trả về của CALL cuối cùng được sử dụng để tái sử dụng tiếp theo returnData []byte }type Cấu trúc hợp đồng { // người gọi địa chỉ của người gọi chung. Địa chỉ // Địa chỉ hợp đồng địa chỉ chung. Địa chỉ jumpdests map[common. Hash]phân tích bitvec bitvec // Mã bytecode hợp đồng []byte // Mã băm mã CodeHash phổ biến. Hash // Đầu vào cuộc gọi []byte // Có nên triển khai IsDeployment bool cho hợp đồng // Có nên gọi IsSystemCall bool // Có sẵn gas gas uint64 // Số lượng ETH gắn liền với giá trị cuộc gọi *uint256. Int }
Các mô-đun khác được thực hiện
Chức năng của lớp thực thi được thực hiện thông qua cách phân lớp, các mô-đun và chức năng khác đều được xây dựng dựa trên ba thành phần cốt lõi này. Dưới đây là một vài mô-đun cốt lõi.
Có các triển khai của các giao thức mạng p2p hiện tại của Ethereum dưới eth/protocols. Có các giao thức con eth/68 và snap, tất cả các giao thức con này đều được xây dựng trên devp2p.
eth/68 là giao thức cốt lõi của Ethereum, tên giao thức là eth, 68 là số phiên bản của nó, và trên cơ sở giao thức này còn thực hiện các chức năng như hồ giao dịch (TxPool), đồng bộ khối (Downloader) và đồng bộ giao dịch (Fetcher). Giao thức snap được sử dụng để đồng bộ nhanh chóng các khối và dữ liệu trạng thái khi nút mới tham gia vào mạng, có thể giảm đáng kể thời gian khởi động của nút mới.
ethdb cung cấp khả năng đọc và ghi cho cơ sở dữ liệu nền tảng, do trong giao thức Ethereum có nhiều cấu trúc dữ liệu phức tạp, nên không thể quản lý dữ liệu này trực tiếp thông qua ethdb, vì vậy đã triển khai rawdb và statedb trên ethdb để quản lý dữ liệu khối và trạng thái một cách riêng biệt.
EVM thì xuyên suốt tất cả các quy trình chính, bất kể là xây dựng khối hay xác thực khối, đều cần thực hiện giao dịch bằng EVM.
05\Geth Nút khởi động quy trình
Geth khởi động sẽ được chia thành hai giai đoạn, giai đoạn đầu tiên sẽ khởi tạo các thành phần và tài nguyên cần thiết để khởi động Nút, giai đoạn thứ hai Nút sẽ chính thức khởi động và sau đó cung cấp dịch vụ ra bên ngoài.
Nút khởi tạo
Khi khởi động một nút geth, sẽ liên quan đến đoạn mã sau:
Các mô-đun được khởi tạo như sau:
Việc khởi tạo Nút sẽ được thực hiện trong makeFullNode của cmd/geth/config.go, chú trọng khởi tạo ba mô-đun sau.
Trong bước đầu tiên, sẽ khởi tạo cấu trúc Node trong file node/node.go, tức là toàn bộ container của nút, tất cả các chức năng cần phải chạy trong container này. Bước thứ hai sẽ khởi tạo cấu trúc Ethereum, trong đó bao gồm việc triển khai các chức năng cốt lõi của Ethereum, Etherereum cũng cần được đăng ký vào Node. Bước thứ ba là đăng ký Engine API vào Node.
Trong đó, việc khởi tạo Nút chính là tạo ra một phiên bản Nút, sau đó khởi tạo máy chủ p2p, quản lý tài khoản và các cổng giao thức http được công khai ra bên ngoài.
Ethereum phức tạp hơn nhiều để khởi tạo và hầu hết các chức năng cốt lõi được khởi tạo ở đây. Đầu tiên, ethdb sẽ được khởi tạo và cấu hình chuỗi sẽ được tải từ bộ lưu trữ, sau đó công cụ đồng thuận sẽ được tạo, trong đó công cụ đồng thuận sẽ không thực hiện các hoạt động đồng thuận mà sẽ chỉ xác minh kết quả được trả về bởi lớp đồng thuận và nếu yêu cầu rút tiền xảy ra trong lớp đồng thuận, hoạt động rút tiền thực tế cũng sẽ được hoàn thành ở đây. Sau đó khởi tạo cấu trúc Block Chain và nhóm giao dịch.
Sau khi hoàn thành tất cả những điều này, handler sẽ được khởi tạo, handler là điểm vào xử lý cho tất cả các yêu cầu mạng p2p, bao gồm đồng bộ giao dịch, tải xuống khối, v.v., là thành phần quan trọng để Ethereum thực hiện hoạt động phi tập trung. Sau khi hoàn thành những điều này, một số giao thức con được triển khai dựa trên devp2p, chẳng hạn như eth/68, snap, sẽ được đăng ký vào container Node, cuối cùng Ethereum sẽ được đăng ký như một lifecycle trong container Node, việc khởi tạo Ethereum hoàn tất.
Cuối cùng, việc khởi tạo Engine API tương đối đơn giản, chỉ cần đăng ký Engine API vào Nút. Đến đây, việc khởi tạo nút đã hoàn tất.
Nút khởi động
Sau khi hoàn thành việc khởi tạo Nút, bạn cần khởi động Nút. Quy trình khởi động Nút tương đối đơn giản, chỉ cần khởi động tất cả các dịch vụ RPC đã đăng ký và Lifecycle, thì toàn bộ Nút có thể cung cấp dịch vụ ra bên ngoài.
06\tóm tắt
Trước khi hiểu được việc triển khai lớp thực thi của Ethereum, cần phải có sự hiểu biết toàn diện về Ethereum, có thể được xem như một máy trạng thái hướng giao dịch, trong đó lớp thực thi chịu trách nhiệm thực hiện các giao dịch và thay đổi trạng thái, và lớp đồng thuận chịu trách nhiệm điều khiển lớp thực thi, bao gồm làm cho lớp thực thi tạo ra các khối, quyết định thứ tự giao dịch, bỏ phiếu cho các khối và tạo các khối cuối cùng. Vì máy trạng thái này được phân cấp, nó cần giao tiếp với các nút khác thông qua mạng P2P để cùng duy trì tính nhất quán của dữ liệu trạng thái.
Tầng thực thi không chịu trách nhiệm quyết định thứ tự giao dịch, chỉ chịu trách nhiệm thực hiện giao dịch và ghi lại sự thay đổi trạng thái sau khi giao dịch được thực hiện. Có hai hình thức ghi lại ở đây, một là ghi lại tất cả sự thay đổi trạng thái dưới dạng khối, hình thức còn lại là ghi lại trạng thái hiện tại trong cơ sở dữ liệu. Cùng lúc, tầng thực thi cũng là điểm vào giao dịch, thông qua hồ giao dịch để lưu trữ các giao dịch chưa được đóng gói vào khối. Nếu các Nút khác cần lấy dữ liệu khối, trạng thái và giao dịch, tầng thực thi sẽ gửi những thông tin này qua mạng p2p.
Đối với lớp thực thi, có ba mô-đun cốt lõi: tính toán, lưu trữ và mạng. Tính toán tương ứng với việc thực hiện EVM, lưu trữ tương ứng với việc thực hiện ethdb, mạng tương ứng với việc thực hiện devp2p. Sau khi có được cái nhìn tổng thể như vậy, bạn có thể đi sâu vào việc hiểu từng mô-đun con mà không bị lạc trong các chi tiết cụ thể.
07\Ref
[1]
[2]
[3]
[4]
[5]
[6]
·KẾT THÚC·
Nội dung | Ray
Chỉnh sửa & Biên tập | Hình Hình
Thiết kế | Daisy