Ця стаття є першою в серії статей про вихідний код Geth. У цій серії ми створимо рамки для дослідження реалізації Geth, і розробники можуть заглибитися в ті частини, які їх цікавлять. У серії всього шість статей, у першій статті ми вивчимо архітектуру дизайну клієнта Geth виконавчого рівня та процес запуску ноди Geth. Код Geth оновлюється дуже швидко, тому код, який ви побачите пізніше, може відрізнятися, але загальний дизайн залишається приблизно однаковим, а новий код можна читати за тим самим принципом.
01\Клієнт Ethereum
До оновлення Ethereum The Merge у Ethereum був лише один клієнт, який відповідав за виконання транзакцій і консенсус блокчейну, гарантуючи, що блокчейн виробляє нові блоки в певному порядку. Після оновлення The Merge клієнт Ethereum поділяється на рівень виконання та рівень консенсусу, рівень виконання відповідає за виконання транзакцій, підтримку стану та даних, рівень консенсусу відповідає за реалізацію функцій консенсусу, а рівень виконання та рівень консенсусу спілкуються через API. Рівень виконання та рівень консенсусу мають свої специфікації, і клієнт може реалізувати їх на різних мовах, але вони повинні відповідати відповідним специфікаціям, а Geth є реалізацією клієнта рівня виконання. На даний момент клієнти основного рівня виконання та рівня консенсусу мають такі реалізації:
Виконавчий рівень
Geth: підтримується командою, яка безпосередньо фінансується Фондом Ethereum, розроблений на мові Go, вважається найстабільнішим і перевіреним клієнтом.
Nethermind: Розроблений і підтримуваний командою Nethermind, написаний мовою C#, на ранніх етапах фінансувався Фондом Ethereum та спільнотою Gitcoin.
Besu: Спочатку розроблений командою PegaSys від ConsenSys, зараз є проектом спільноти Hyperledger, розроблений мовою Java
Erigon: Розроблений і підтримуваний командою Erigon, фінансований Фондом Ethereum та BNB Chain. Виник з Geth у 2017 році, мета - підвищити швидкість синхронізації та ефективність диска.
Reth: розроблений під керівництвом Paradigm, мова розробки - Rust, акцент на модульності та високій продуктивності, наразі вже наближається до зрілості, може використовуватись у виробничому середовищі.
Шар консенсусу
Prysm: утримується Prysmatic Labs, є одним з перших клієнтів рівня консенсусу Ethereum, розроблений мовою Go, зосереджений на зручності використання та безпеці, на початковому етапі отримав фінансування від фонду Ethereum.
Lighthouse: підтримується командою Sigma Prime, розроблений мовою Rust, орієнтований на високу продуктивність і корпоративну безпеку, підходить для сценаріїв з високим навантаженням
Teku: Ранковий проект, розроблений командою PegaSys від ConsenSys, який згодом став частиною спільноти Hyperledger Besu, розроблений мовою Java.
Nimbus: Розроблений і підтримуваний командою Status Network, написаний мовою Nim, оптимізований для пристроїв з обмеженими ресурсами (таких як мобільні телефони, пристрої Інтернету речей), мета полягає в реалізації легковагового виконання в вбудованих системах.
02\Огляд виконавчого рівня
Ефірну виконувальну платформу можна розглядати як станову машину, що керується транзакціями. Найбазовіша функція виконувального рівня полягає в оновленні стану даних шляхом виконання транзакцій через EVM. Окрім виконання транзакцій, також є функції збереження та верифікації блоків і стану даних, роботи p2p мережі та підтримки пулу транзакцій.
Транзакції генеруються користувачем (або програмою) у форматі, визначеному специфікацією виконавчого рівня Ethereum. Користувач повинен підписати транзакцію, і якщо транзакція є законною (Nonce послідовна, підпис вірний, плата за газ достатня, бізнес-логіка правильна), тоді транзакція врешті-решт буде виконана EVM, оновлюючи стан мережі Ethereum. Тут стан відноситься до колекції структур даних, даних і бази даних, включаючи адреси зовнішніх рахунків, адреси контрактів, баланси адрес та код і дані.
Виконавчий рівень відповідає за виконання транзакцій та підтримку стану після виконання транзакцій, тоді як рівень консенсусу відповідає за вибір транзакцій, які потрібно виконати. EVM є функцією перетворення стану в цій машині стану, вхідні дані функції можуть надходити з кількох джерел, зокрема з останньої інформації про блоки, наданої рівнем консенсусу, або з блоків, завантажених з p2p мережі.
Консенсусний рівень та рівень виконання взаємодіють через Engine API, це єдиний спосіб зв'язку між рівнем виконання та консенсусним рівнем. Якщо консенсусний рівень отримав право на створення блоку, він через Engine API дозволить рівню виконання створити новий блок, якщо ж право на створення блоку не отримано, він синхронізує останній блок, щоб рівень виконання міг його перевірити та виконати, таким чином підтримуючи консенсус з усією мережею Ethereum.
Виконавчий рівень логічно можна поділити на 6 частин:
EVM: відповідає за виконання транзакцій, виконання транзакцій також є єдиним способом зміни стану
Сховище: відповідає за зберігання таких даних, як стан і блоки
Торговий пул: використовується для поданих користувачем транзакцій, тимчасово зберігається та буде поширюватися через p2p мережу між різними Нодами.
p2p мережа: використовується для виявлення Нод, синхронізації транзакцій, завантаження блоків тощо
Сервіс RPC: надає можливість доступу до вузлів, таких як користувачі, які надсилають транзакції вузлам, і взаємодія між рівнем консенсусу та рівнем виконання
BlockChain: відповідальний за управління даними блокчейну Ethereum
Нижче наведено ключові процеси виконавчого рівня та функції кожної частини:
Для виконавчого рівня (тут тимчасово обговорюємо лише Full Node) є три ключові процеси:
Якщо це вузол, який приєднується до Ethereum, йому потрібно синхронізувати дані блоку та стану з інших вузлів через мережу p2p, якщо це Full Sync, він завантажуватиме блоки один за одним із генезис-блоку, перевірятиме блоки та перебудовуватиме базу даних стану через EVM, якщо це Snap Sync, пропускатиме процес перевірки всіх блоків і безпосередньо завантажуватиме дані стану останньої контрольної точки та майбутніх даних блоку
Якщо це вже синхронізована до останнього стану Нода, то вона буде постійно отримувати через Engine API з рівня консенсусу поточний останній видобутий блок, перевіряти блок, а потім виконувати всі транзакції в блоці через EVM для оновлення бази даних стану та записувати блок у локальний ланцюг.
Якщо це вузол, який був синхронізований з останнім станом, і рівень консенсусу отримав право генерації блоків, він змусить виконавчий рівень створити останній блок через Engine API, а виконавчий рівень отримає транзакцію з пулу транзакцій і виконає її, а потім збере її в блок і передасть на рівень консенсусу через Engine API, а рівень консенсусу транслюватиме блок у p2p-мережу рівня консенсусу
03\Структура коду
Структура коду go-ethereum дуже велика, але багато з цього коду є допоміжним і тестами на одиницях. При вивченні вихідного коду Geth потрібно зосередитися на основній реалізації протоколу, функції різних модулів такі: необхідно особливо звернути увагу на модулі core, eth, ethdb, node, p2p, rlp, trie & triedb тощо.
облікові записи: управління обліковими записами Ethereum, включаючи генерацію пари публічного та приватного ключів, перевірку підписів, деривацію адрес тощо
Beacon: обробляє логіку взаємодії з Ethereum Beacon Chain і підтримує функцію консенсусу Proof-of-Stake (PoS) після злиття
build：скрипти збірки та конфігурації компіляції (такі як Dockerfile, підтримка крос-платформеної компіляції)
cmd: вхідний інтерфейс командного рядка, що містить кілька підкоманд
загальні: універсальні утиліти, такі як обробка байтів, перетворення формату адреси, математичні функції
консенсус: визначення консенсус-двигуна, включаючи попередній механізм доказу роботи (Ethash) та одноосібний механізм доказу частки (Clique), а також Beacon engine тощо
console: Надає інтерактивну консоль JavaScript, яка дозволяє користувачам безпосередньо взаємодіяти з вузлами Ethereum через командний рядок (наприклад, виклик Web3 API, керування обліковими записами, запит даних блокчейну)
core: основна логіка блокчейну, управління життєвим циклом блоків/транзакцій, автомат станів, обчислення Gas тощо
docs: документація (наприклад, дизайн-стандарти, опис API)
eth: Повна реалізація протоколу мережі Ethereum, включаючи послуги ноди, синхронізацію блоків (таких як швидка синхронізація, архівний режим), трансляцію транзакцій тощо
ethclient: реалізація бібліотеки клієнта Ethereum, що інкапсулює інтерфейс JSON-RPC, для взаємодії розробників Go з Нодою Ethereum (наприклад, запит блоків, відправка транзакцій, розгортання контрактів)
ethdb: абстрактний рівень бази даних, що підтримує LevelDB, Pebble, бази даних в пам'яті тощо, зберігає дані блокчейну (блоки, стан, транзакції)
ethstats: збирає та повідомляє про стан роботи Ноди до статистичного сервісу, використовується для моніторингу здоров'я мережі
подія：реалізувати механізм підписки та публікації подій, підтримувати асинхронну комунікацію між внутрішніми модулями ноди (наприклад, прибуття нового блоку, оновлення пулу транзакцій)
graphql: надає GraphQL інтерфейс, підтримує складні запити (замінює частину функцій JSON-RPC)
internal：Внутрішні інструменти або код, який обмежує зовнішній доступ
log: Журнал системи, підтримує багаторівневий вивід журналів, запис контекстних журналів
майнер: логіка, пов'язана з видобутком, створення нових блоків та упаковка транзакцій (в сценах PoW)
Node: управління сервісами вузлів, інтеграція запуску та налаштування p2p, RPC, баз даних та інших модулів
p2p: реалізація протоколу мережі «точка-точка», підтримує виявлення Нод, передачу даних, шифровану комунікацію
params：визначити параметри мережі Ethereum (головна мережа, тестова мережа, конфігурація генезис-блоку)
rlp: реалізує спеціальний протокол серіалізації даних Ethereum RLP (Recursive Length Prefix), призначений для кодування/декодування блоків, транзакцій та інших структур даних.
rpc: реалізація JSON-RPC та IPC інтерфейсів для зовнішніх програм для взаємодії з Нодою
тести: інтеграційні тести та тести стану, перевірка сумісності протоколу
trie & triedb: реалізація дерева Меркла-Патриції (Merkle Patricia Trie) для ефективного зберігання та управління станом облікових записів, зберіганням контрактів
04\Розподіл модулів виконавчого рівня
Існує два способи зовнішнього доступу до Geth Ноди: один - через RPC, інший - через Консоль. RPC підходить для надання доступу зовнішнім користувачам, а Консоль підходить для використання адміністраторами Ноди. Але незалежно від того, чи через RPC, чи через Консоль, обидва використовують внутрішні вже упаковані можливості, які побудовані за принципом багаторівневості.
Найзовнішній шар - це API, який забезпечує зовнішній доступ до можливостей ноди, Engine API використовується для зв'язку між виконавчим і консенсусним шарами, Eth API призначений для зовнішніх користувачів або програм для відправки транзакцій, отримання інформації про блоки, Net API використовується для отримання стану p2p мережі і так далі. Наприклад, якщо користувач відправляє транзакцію через API, ця транзакція в кінцевому підсумку буде відправлена до пулу транзакцій, який управляє нею. Ще один приклад: якщо користувачеві потрібно отримати дані про блок, то потрібно викликати можливості бази даних для отримання відповідного блоку.
На наступному рівні API реалізація основних функцій включає в себе об'єднання транзакцій, упаковку транзакцій, виробництво блоків, синхронізацію блоків і станів і т.д. Ці функції повинні покладатися на можливості нижчого рівня, такі як здатність мережі P2P синхронізувати пули транзакцій, блоки та стани, а генерація блоків і блоків, синхронізованих з іншими вузлами, повинна бути перевірена, перш ніж їх можна буде записати в локальну базу даних, яка повинна покладатися на можливості EVM і зберігання даних.
Структура Ethereum в eth/backend.go - це абстракція всього протоколу Ethereum, який в основному включає основні компоненти Ethereum, за винятком EVM, який створюється щоразу, коли обробляється транзакція, і його не потрібно ініціалізувати всім вузлом.
тип Ethereum struct { // Конфігурація Ethereum, включаючи конфігурацію ланцюжка *ethconfig. Config // Пул транзакцій, після того, як транзакція користувача відправлена, переходимо в пул транзакцій txPool *txpool. TxPool // Використовується для відстеження та управління локальними транзакціями localTxTracker *locals. TxTracker // Структура блокчейну *core. BlockChain // є основним компонентом мережевого рівня вузла Ethereum, відповідальним за обробку всього зв'язку з іншими вузлами, включаючи синхронізацію блоків, трансляцію та отримання транзакцій, а також управління обробником з'єднання вузлів з одноранговими вузлами // відповідає за виявлення вузлів та керування вихідним кодом вузлів *enode. FairMix // Відповідає за постійне зберігання ланцюжка даних блокчейнуDb ethdb. База даних // Відповідає за публікацію та підписку на різні внутрішні події eventMux *event. TypeMux // Консенсус движка. Движок // Управління обліковими записами користувачів і ключами accountManager *accounts. Менеджер // Управління фільтрами журналів і фрагментами фільтрівMaps *filtermaps. FilterMaps // Канал для безпечного вимкнення filterMaps, забезпечення правильного очищення ресурсів при вимкненні вузлів closeFilterMaps chan chan struct{} // Забезпечення підтримки серверної частини для RPC API APIBackend *EthAPIBackend // Під PoS працюйте з движком консенсусу для перевірки блокового майнера *miner. Майнер // Найнижча ціна на газ, прийнята вузлом - gasPrice *big. Int // Network ID networkID uint64 // Надавати послуги RPC, пов'язані з мережею, дозволяючи запитувати статус мережі через RPC netRPCService *ethapi. NetAPI // Управління мережевими з'єднаннями P2P, виявлення вузлів і встановлення з'єднань, а також надання функцій мережевого транспорту p2pServer *p2p. Сервер // Захист одночасного доступу до змінних полів блокування синхронізації. RWMutex // Відстежує, чи коректно не працює вузол і допомагає відновити shutdownTracker після аномального завершення роботи *shutdowncheck. ShutdownTracker }
Нода
Node в node/node.go - це ще одна основна структура даних, яка діє як контейнер для управління та координації роботи різних сервісів. У наведеній нижче структурі важливо зосередитися на полі життєвих циклів, яке життєві цикли використовують для управління життєвим циклом внутрішніх функцій. Наприклад, наведена вище абстракція Ethereum повинна покладатися на Node для запуску та реєстрації в життєвих циклах. Таким чином, конкретні функції можуть бути відокремлені від абстракції вузла, а масштабованість всієї архітектури повинна бути диференційована, яку потрібно відрізняти від вузла в devp2p.
type Node struct { eventmux *event. TypeMux config *Config // Менеджер по роботі з клієнтами, відповідальний за управління гаманцями і рахунками accman *accounts. Журнал журналу менеджера. Logger keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // p2p network instance server *p2p. Синхронізація startStopLock сервера. Mutex // Стан життєвого циклу вузла (ініціалізований, запущений, закритий) стан int lock sync. Mutex // Життєві цикли всіх зареєстрованих бекендів, сервісів та допоміжних служб []Життєвий цикл // Список доступних API на даний момент rpcAPI []rpc. API // Різні методи доступу до RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Server databases map[*closeTrackingDB]struct{} }
Якщо дивитися на виконавчий рівень Ethereum з абстрактної точки зору, Ethereum як світовий комп'ютер повинен включати три частини: мережу, обчислення та зберігання. Отже, компоненти, які відповідають цим трьом частинам на виконавчому рівні Ethereum, це:
Мережа: devp2p
Обчислення: EVM
Зберігання: ethdb
devp2p
Ефіріум по суті є розподіленою системою, кожна Нода з'єднується з іншими Нодами через p2p мережу. Реалізація p2p мережевого протоколу в Ефіріумі — це devp2p.
devp2p має дві основні функції: перша – це виявлення нод, що дозволяє нодам встановлювати зв'язок з іншими нодами при підключенні до мережі; друга – це служба передачі даних, яка дозволяє обмінюватися даними після встановлення зв'язку з іншими нодами.
У структурі Node у p2p/enode/node.go представлено ноду в p2p мережі, де в структурі enr.Record зберігаються пари ключ-значення з детальною інформацією про ноду, включаючи ідентифікаційну інформацію (алгоритм підпису, що використовується для ідентифікації ноди, публічний ключ), мережеву інформацію (IP-адреса, номер порту), інформацію про підтримувані протоколи (наприклад, підтримка протоколів eth/68 та snap) та іншу користувацьку інформацію. Ця інформація кодується за допомогою RLP, конкретні вимоги визначені в eip-778:
type Node struct { // Нода запису, містить різні властивості ноди r enr.Record // Унікальний ідентифікатор ноди, довжина 32 байти id ID // hostname DNS-ім'я ноди hostname string // IP-адреса ноди ip netip.Addr // UDP порт udp uint16 // TCP порт tcp uint16 }// enr.Recordtype Record struct { // Серійний номер seq uint64 // Підпис signature []byte // RLP закодоване запис raw []byte // Відсортований список усіх пар ключ-значення pairs []pair }
У структурі Table, що знаходиться в p2p/discover/table.go, реалізується основна структура даних для протоколу виявлення нод devp2p. Вона реалізує розподілену хеш-таблицю, схожу на Kademlia, для підтримки та управління інформацією про ноди в мережі.
printf("type Table struct { mutex sync. Mutex // Індексувати відомі сегменти вузлів за відстанню [nBuckets]*bucket // початковий вузол nursery []*enode. Node rand resedingRandom ips netutil. Таблиця ревалідації DistinctNetSetRevalidation // База даних відомих вузлів db *enode. DB net transport cfg Config log log. Logger // Періодично обробляє різні події в мережі 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{} // Додавання та видалення інтерфейсів для вузлів nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(* відро, *tableNode)} світ!» );
ethdb
ethdb завершив абстракцію зберігання даних Ethereum, надаючи єдиний інтерфейс зберігання; підкладковою конкретною базою даних може бути leveldb, pebble або інша база даних. Можна мати багато розширень, якщо на рівні інтерфейсу зберігати єдність.
Деякі дані (наприклад, блокові дані) можуть бути безпосередньо прочитані та записані в базову базу даних через інтерфейс ethdb, а інші інтерфейси зберігання даних базуються на ethdb, наприклад, значна частина даних у базі даних є даними стану, які будуть організовані в структуру MPT, і відповідна реалізація в Geth є trie управляти цими даними і проміжним станом, і, нарешті, зберігати їх через ethdb.
Інтерфейс, який визначає можливості читання та запису базової бази даних у ethdb/database.go, не включає конкретну реалізацію, яка буде реалізована самими різними базами даних. Наприклад, бази даних leveldb або pebble. У базі даних визначено два рівні інтерфейсів читання/запису даних, серед яких інтерфейс KeyValueStore використовується для зберігання активних даних, що часто змінюються, таких як останній блок, стан тощо. AncientStore використовується для обробки історичних фрагментів даних, які рідко змінюються після написання.
// Топ-інтерфейс бази даних типу Database інтерфейс { KeyValueStore AncientStore}// Інтерфейс читання та запису KV даних типу KeyValueStore інтерфейс { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee Compacter io.Closer}// Інтерфейс для обробки старих даних читання та запису типу AncientStore інтерфейс { AncientReader AncientWriter AncientStater io.Closer}
EVM
EVM є функцією перетворення стану цього станового автомата Ethereum, всі оновлення стану даних можуть здійснюватися лише через EVM, p2p мережа може отримувати інформацію про транзакції та блоки, ця інформація після обробки EVM стане частиною бази даних стану. EVM приховує різницю між підключеним апаратним забезпеченням, що дозволяє програмам отримувати однакові результати при виконанні на різних платформах EVM. Це дуже зріла дизайнерська концепція, аналогічний дизайн існує також у Java мові, де JVM виконує подібну функцію.
Існування EVM має три основні компоненти: структура EVM, визначена в core/vm/evm.go, визначає загальну структуру EVM та залежності, включаючи контекст виконання, залежності від бази даних стану тощо; структура EVMInterpreter, визначена в core/vm/interpreter.go, реалізує інтерпретатор, відповідальний за виконання EVM байт-коду; структура Contract в core/vm/contract.go інкапсулює конкретні параметри виклику контракту, включаючи викликувача, код контракту, вхідні дані тощо, а також у core/vm/opcodes.go визначено всі поточні кодові операції:
EVMtype EVM struct { // Контекст блоку, що містить інформацію, пов'язану з блоком Context BlockContext // Контекст транзакції, що містить інформацію, пов'язану з транзакцією TxContext // База даних станів, що використовується для доступу та зміни стану облікового запису StateDB StateDB // Глибина поточного виклику int // Параметр конфігурації ланцюжка chainConfig *params. ChainConfig chainRules параметри. Rules // EVM Config Config // Інтерпретатор байт-коду *EVMInterpreter // Перервати прапор виконання abort atomic. Bool callGasTemp uint64 // прекомпілює map[common. Address]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // Вказати на екземпляр EVM, до якого він належить evm *EVM // Таблиця переходів коду операції *JumpTable // Кешер екземпляр Keccak256, обмінюватися хешер-крипто між кодами операцій. KeccakState // Keccak256 хеш-результат буфер hasherBuf загальний. Hash // Незалежно від того, чи це режим тільки для читання, модифікація стану не допускається в режимі тільки читання readOnly bool // Для подальшого повторного використання використовуються дані останнього CALL returnData []byte }type Contract struct { // адреса абонента caller common. Адреса // Адреса контракту загальна. Карта стрибків адрес[загальна. Hash]bitvec аналіз bitvec // Контракт Байт-код Код []байт // Код хеш CodeHash загальний. Hash // Call input []byte // Чи розгортати булеве значення IsDeployment для контракту // Чи викликати булеве значення IsSystemCall // Доступний газовий газ uint64 // Кількість ETH, прикріплена до значення виклику *uint256. Int }
Інші модулі реалізації
Функції виконавчого рівня реалізуються за допомогою багаторівневої структури, а інші модулі та функції побудовані на основі цих трьох основних компонентів. Тут представлено кілька основних модулів.
У eth/protocols є реалізація поточних підпротоколів p2p мережі Ethereum. Є підпротоколи eth/68 і snap, які побудовані на devp2p.
eth/68 є основним протоколом Ethereum, назва протоколу - це eth, 68 - його номер версії, а на основі цього протоколу реалізовані такі функції, як пул транзакцій (TxPool), синхронізація блоків (Downloader) та синхронізація транзакцій (Fetcher). Протокол snap використовується для швидкої синхронізації блоків та стану даних, коли нова нода приєднується до мережі, що може значно зменшити час запуску нової ноди.
ethdb надає можливості читання та запису для бази даних на нижньому рівні. Оскільки в протоколі Ethereum є багато складних структур даних, безпосередньо через ethdb неможливо реалізувати управління цими даними, тому на ethdb були реалізовані rawdb та statedb для окремого управління блоками та станом даних.
EVM пронизує всі основні процеси, незалежно від того, чи це побудова блоку, чи верифікація блоку, все одно потрібно використовувати EVM для виконання транзакцій.
05\Geth Нода запуск процесу
Запуск Geth поділиться на два етапи: перший етап ініціалізує компоненти та ресурси, необхідні для запуску Ноди, другий етап офіційно запустить Ноду, а потім надасть зовнішні послуги.
eth/ethconfig/config.go: ініціалізація екземпляра консенсусного двигуна (цей консенсусний двигун насправді не бере участі в консенсусі, а лише перевіряє результати консенсусного шару та обробляє запити на виведення валідаторів)
cmd/utils/flags.go(Реєстрація GraphQL-сервісу)：реєстрація GraphQL RPC API (якщо конфігуровано)
cmd/utils/flags.go(Реєстрація EthStatsService): реєстрація EthStats RPC API (якщо налаштовано)
eth/catalyst/api.go: Зареєструйте API рушія
Ініціалізація Ноди буде виконана в makeFullNode у файлі cmd/geth/config.go, з акцентом на ініціалізацію наступних трьох модулів.
На першому етапі буде ініціалізовано структуру Node у node/node.go, яка є всім контейнером ноди, всі функції повинні виконуватись у цьому контейнері. На другому етапі буде ініціалізовано структуру Ethereum, яка включає реалізацію різноманітних основних функцій Ethereum. Etherereum також потрібно зареєструвати в Node. Третій етап полягає в реєстрації Engine API в Node.
Ініціалізація Нода полягає у створенні екземпляра Нода, а також у ініціалізації p2p сервера, управління обліковими записами та http тощо, що надаються зовнішнім протоколам.
Ініціалізація Ethereum буде набагато складнішою, більшість основних функцій ініціалізуються тут. По-перше, ініціалізується ethdb та завантажується конфігурація ланцюга зі сховища, потім створюється консенсусний двигун, який не виконує операції консенсусу, а лише перевіряє результати, що повертаються консенсусним шаром. Якщо в консенсусному шарі виникає запит на виведення, фактична операція виведення також виконується тут. Потім ініціалізується структура блокчейну та пул транзакцій.
Як тільки це зроблено, ініціалізується обробник, який є точкою входу для всіх запитів мережі P2P, включаючи синхронізацію транзакцій, завантаження блоків тощо, і є ключовим компонентом децентралізованої роботи Ethereum. Після того, як вони будуть завершені, деякі підпротоколи, реалізовані на основі devp2p, такі як eth/68, snap тощо, будуть зареєстровані в контейнері Node, і, нарешті, Ethereum буде зареєстровано як життєвий цикл у контейнері Node, а ініціалізація Ethereum буде завершена.
Врешті-решт ініціалізація Engine API є відносно простою, просто зареєструвати Engine API в Ноді. На цьому етапі ініціалізація вузла повністю завершена.
Нода запуску
Після завершення ініціалізації Ноди необхідно запустити Ноду. Процес запуску Ноди відносно простий: потрібно лише запустити всі зареєстровані RPC-сервіси та Lifecycle, після чого вся Нода зможе надавати послуги зовнішньому світу.
06\резюме
Перш ніж глибше зрозуміти реалізацію виконавчого рівня Ethereum, необхідно мати загальне уявлення про Ethereum. В цілому Ethereum можна розглядати як транзакційно-орієнтовану машину станів, де виконавчий рівень відповідає за виконання транзакцій та зміни стану, а рівень консенсусу відповідає за управління роботою виконавчого рівня, включаючи створення блоків, визначення порядку транзакцій, голосування за блоки та надання блокам остаточності. Оскільки ця машина станів є децентралізованою, необхідно спілкуватися з іншими Нода через p2p мережу для спільного підтримання узгодженості стану даних.
Виконавчий рівень не відповідає за визначення порядку транзакцій, а лише за виконання транзакцій та запис змін стану після виконання транзакцій. Записи тут мають два формати: один - це блоковий формат, в якому всі зміни стану записуються, інший - це запис поточного стану в базі даних. Водночас виконавчий рівень є входом для транзакцій, зберігаючи ще не упаковані в блок транзакції в пулі транзакцій. Якщо інші ноди потребують отримати дані про блоки, стан та транзакції, виконавчий рівень через p2p мережу надсилає цю інформацію.
Для виконавчого рівня є три основні модулі: обчислення, зберігання та мережа. Обчислення відповідає реалізації EVM, зберігання відповідає реалізації ethdb, а мережа відповідає реалізації devp2p. Маючи таке загальне розуміння, можна глибше зрозуміти кожен підмодуль, не гублячись у конкретних деталях.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Ethereum основний клієнт: архітектура Geth
Ця стаття є першою в серії статей про вихідний код Geth. У цій серії ми створимо рамки для дослідження реалізації Geth, і розробники можуть заглибитися в ті частини, які їх цікавлять. У серії всього шість статей, у першій статті ми вивчимо архітектуру дизайну клієнта Geth виконавчого рівня та процес запуску ноди Geth. Код Geth оновлюється дуже швидко, тому код, який ви побачите пізніше, може відрізнятися, але загальний дизайн залишається приблизно однаковим, а новий код можна читати за тим самим принципом.
01\Клієнт Ethereum
До оновлення Ethereum The Merge у Ethereum був лише один клієнт, який відповідав за виконання транзакцій і консенсус блокчейну, гарантуючи, що блокчейн виробляє нові блоки в певному порядку. Після оновлення The Merge клієнт Ethereum поділяється на рівень виконання та рівень консенсусу, рівень виконання відповідає за виконання транзакцій, підтримку стану та даних, рівень консенсусу відповідає за реалізацію функцій консенсусу, а рівень виконання та рівень консенсусу спілкуються через API. Рівень виконання та рівень консенсусу мають свої специфікації, і клієнт може реалізувати їх на різних мовах, але вони повинні відповідати відповідним специфікаціям, а Geth є реалізацією клієнта рівня виконання. На даний момент клієнти основного рівня виконання та рівня консенсусу мають такі реалізації:
Виконавчий рівень
Шар консенсусу
02\Огляд виконавчого рівня
Ефірну виконувальну платформу можна розглядати як станову машину, що керується транзакціями. Найбазовіша функція виконувального рівня полягає в оновленні стану даних шляхом виконання транзакцій через EVM. Окрім виконання транзакцій, також є функції збереження та верифікації блоків і стану даних, роботи p2p мережі та підтримки пулу транзакцій.
Транзакції генеруються користувачем (або програмою) у форматі, визначеному специфікацією виконавчого рівня Ethereum. Користувач повинен підписати транзакцію, і якщо транзакція є законною (Nonce послідовна, підпис вірний, плата за газ достатня, бізнес-логіка правильна), тоді транзакція врешті-решт буде виконана EVM, оновлюючи стан мережі Ethereum. Тут стан відноситься до колекції структур даних, даних і бази даних, включаючи адреси зовнішніх рахунків, адреси контрактів, баланси адрес та код і дані.
Виконавчий рівень відповідає за виконання транзакцій та підтримку стану після виконання транзакцій, тоді як рівень консенсусу відповідає за вибір транзакцій, які потрібно виконати. EVM є функцією перетворення стану в цій машині стану, вхідні дані функції можуть надходити з кількох джерел, зокрема з останньої інформації про блоки, наданої рівнем консенсусу, або з блоків, завантажених з p2p мережі.
Консенсусний рівень та рівень виконання взаємодіють через Engine API, це єдиний спосіб зв'язку між рівнем виконання та консенсусним рівнем. Якщо консенсусний рівень отримав право на створення блоку, він через Engine API дозволить рівню виконання створити новий блок, якщо ж право на створення блоку не отримано, він синхронізує останній блок, щоб рівень виконання міг його перевірити та виконати, таким чином підтримуючи консенсус з усією мережею Ethereum.
Виконавчий рівень логічно можна поділити на 6 частин:
Нижче наведено ключові процеси виконавчого рівня та функції кожної частини:
Для виконавчого рівня (тут тимчасово обговорюємо лише Full Node) є три ключові процеси:
03\Структура коду
Структура коду go-ethereum дуже велика, але багато з цього коду є допоміжним і тестами на одиницях. При вивченні вихідного коду Geth потрібно зосередитися на основній реалізації протоколу, функції різних модулів такі: необхідно особливо звернути увагу на модулі core, eth, ethdb, node, p2p, rlp, trie & triedb тощо.
04\Розподіл модулів виконавчого рівня
Існує два способи зовнішнього доступу до Geth Ноди: один - через RPC, інший - через Консоль. RPC підходить для надання доступу зовнішнім користувачам, а Консоль підходить для використання адміністраторами Ноди. Але незалежно від того, чи через RPC, чи через Консоль, обидва використовують внутрішні вже упаковані можливості, які побудовані за принципом багаторівневості.
Найзовнішній шар - це API, який забезпечує зовнішній доступ до можливостей ноди, Engine API використовується для зв'язку між виконавчим і консенсусним шарами, Eth API призначений для зовнішніх користувачів або програм для відправки транзакцій, отримання інформації про блоки, Net API використовується для отримання стану p2p мережі і так далі. Наприклад, якщо користувач відправляє транзакцію через API, ця транзакція в кінцевому підсумку буде відправлена до пулу транзакцій, який управляє нею. Ще один приклад: якщо користувачеві потрібно отримати дані про блок, то потрібно викликати можливості бази даних для отримання відповідного блоку.
На наступному рівні API реалізація основних функцій включає в себе об'єднання транзакцій, упаковку транзакцій, виробництво блоків, синхронізацію блоків і станів і т.д. Ці функції повинні покладатися на можливості нижчого рівня, такі як здатність мережі P2P синхронізувати пули транзакцій, блоки та стани, а генерація блоків і блоків, синхронізованих з іншими вузлами, повинна бути перевірена, перш ніж їх можна буде записати в локальну базу даних, яка повинна покладатися на можливості EVM і зберігання даних.
! Основний клієнт Ethereum: загальна архітектура Geth
Ядро структур даних виконавчого рівня
Ефіріум
Структура Ethereum в eth/backend.go - це абстракція всього протоколу Ethereum, який в основному включає основні компоненти Ethereum, за винятком EVM, який створюється щоразу, коли обробляється транзакція, і його не потрібно ініціалізувати всім вузлом.
тип Ethereum struct { // Конфігурація Ethereum, включаючи конфігурацію ланцюжка *ethconfig. Config // Пул транзакцій, після того, як транзакція користувача відправлена, переходимо в пул транзакцій txPool *txpool. TxPool // Використовується для відстеження та управління локальними транзакціями localTxTracker *locals. TxTracker // Структура блокчейну *core. BlockChain // є основним компонентом мережевого рівня вузла Ethereum, відповідальним за обробку всього зв'язку з іншими вузлами, включаючи синхронізацію блоків, трансляцію та отримання транзакцій, а також управління обробником з'єднання вузлів з одноранговими вузлами // відповідає за виявлення вузлів та керування вихідним кодом вузлів *enode. FairMix // Відповідає за постійне зберігання ланцюжка даних блокчейнуDb ethdb. База даних // Відповідає за публікацію та підписку на різні внутрішні події eventMux *event. TypeMux // Консенсус движка. Движок // Управління обліковими записами користувачів і ключами accountManager *accounts. Менеджер // Управління фільтрами журналів і фрагментами фільтрівMaps *filtermaps. FilterMaps // Канал для безпечного вимкнення filterMaps, забезпечення правильного очищення ресурсів при вимкненні вузлів closeFilterMaps chan chan struct{} // Забезпечення підтримки серверної частини для RPC API APIBackend *EthAPIBackend // Під PoS працюйте з движком консенсусу для перевірки блокового майнера *miner. Майнер // Найнижча ціна на газ, прийнята вузлом - gasPrice *big. Int // Network ID networkID uint64 // Надавати послуги RPC, пов'язані з мережею, дозволяючи запитувати статус мережі через RPC netRPCService *ethapi. NetAPI // Управління мережевими з'єднаннями P2P, виявлення вузлів і встановлення з'єднань, а також надання функцій мережевого транспорту p2pServer *p2p. Сервер // Захист одночасного доступу до змінних полів блокування синхронізації. RWMutex // Відстежує, чи коректно не працює вузол і допомагає відновити shutdownTracker після аномального завершення роботи *shutdowncheck. ShutdownTracker }
Нода
Node в node/node.go - це ще одна основна структура даних, яка діє як контейнер для управління та координації роботи різних сервісів. У наведеній нижче структурі важливо зосередитися на полі життєвих циклів, яке життєві цикли використовують для управління життєвим циклом внутрішніх функцій. Наприклад, наведена вище абстракція Ethereum повинна покладатися на Node для запуску та реєстрації в життєвих циклах. Таким чином, конкретні функції можуть бути відокремлені від абстракції вузла, а масштабованість всієї архітектури повинна бути диференційована, яку потрібно відрізняти від вузла в devp2p.
type Node struct { eventmux *event. TypeMux config *Config // Менеджер по роботі з клієнтами, відповідальний за управління гаманцями і рахунками accman *accounts. Журнал журналу менеджера. Logger keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // p2p network instance server *p2p. Синхронізація startStopLock сервера. Mutex // Стан життєвого циклу вузла (ініціалізований, запущений, закритий) стан int lock sync. Mutex // Життєві цикли всіх зареєстрованих бекендів, сервісів та допоміжних служб []Життєвий цикл // Список доступних API на даний момент rpcAPI []rpc. API // Різні методи доступу до RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Server databases map[*closeTrackingDB]struct{} }
Якщо дивитися на виконавчий рівень Ethereum з абстрактної точки зору, Ethereum як світовий комп'ютер повинен включати три частини: мережу, обчислення та зберігання. Отже, компоненти, які відповідають цим трьом частинам на виконавчому рівні Ethereum, це:
devp2p
Ефіріум по суті є розподіленою системою, кожна Нода з'єднується з іншими Нодами через p2p мережу. Реалізація p2p мережевого протоколу в Ефіріумі — це devp2p.
devp2p має дві основні функції: перша – це виявлення нод, що дозволяє нодам встановлювати зв'язок з іншими нодами при підключенні до мережі; друга – це служба передачі даних, яка дозволяє обмінюватися даними після встановлення зв'язку з іншими нодами.
У структурі Node у p2p/enode/node.go представлено ноду в p2p мережі, де в структурі enr.Record зберігаються пари ключ-значення з детальною інформацією про ноду, включаючи ідентифікаційну інформацію (алгоритм підпису, що використовується для ідентифікації ноди, публічний ключ), мережеву інформацію (IP-адреса, номер порту), інформацію про підтримувані протоколи (наприклад, підтримка протоколів eth/68 та snap) та іншу користувацьку інформацію. Ця інформація кодується за допомогою RLP, конкретні вимоги визначені в eip-778:
type Node struct { // Нода запису, містить різні властивості ноди r enr.Record // Унікальний ідентифікатор ноди, довжина 32 байти id ID // hostname DNS-ім'я ноди hostname string // IP-адреса ноди ip netip.Addr // UDP порт udp uint16 // TCP порт tcp uint16 }// enr.Recordtype Record struct { // Серійний номер seq uint64 // Підпис signature []byte // RLP закодоване запис raw []byte // Відсортований список усіх пар ключ-значення pairs []pair }
У структурі Table, що знаходиться в p2p/discover/table.go, реалізується основна структура даних для протоколу виявлення нод devp2p. Вона реалізує розподілену хеш-таблицю, схожу на Kademlia, для підтримки та управління інформацією про ноди в мережі.
printf("type Table struct { mutex sync. Mutex // Індексувати відомі сегменти вузлів за відстанню [nBuckets]*bucket // початковий вузол nursery []*enode. Node rand resedingRandom ips netutil. Таблиця ревалідації DistinctNetSetRevalidation // База даних відомих вузлів db *enode. DB net transport cfg Config log log. Logger // Періодично обробляє різні події в мережі 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{} // Додавання та видалення інтерфейсів для вузлів nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(* відро, *tableNode)} світ!» );
ethdb
ethdb завершив абстракцію зберігання даних Ethereum, надаючи єдиний інтерфейс зберігання; підкладковою конкретною базою даних може бути leveldb, pebble або інша база даних. Можна мати багато розширень, якщо на рівні інтерфейсу зберігати єдність.
Деякі дані (наприклад, блокові дані) можуть бути безпосередньо прочитані та записані в базову базу даних через інтерфейс ethdb, а інші інтерфейси зберігання даних базуються на ethdb, наприклад, значна частина даних у базі даних є даними стану, які будуть організовані в структуру MPT, і відповідна реалізація в Geth є trie управляти цими даними і проміжним станом, і, нарешті, зберігати їх через ethdb.
Інтерфейс, який визначає можливості читання та запису базової бази даних у ethdb/database.go, не включає конкретну реалізацію, яка буде реалізована самими різними базами даних. Наприклад, бази даних leveldb або pebble. У базі даних визначено два рівні інтерфейсів читання/запису даних, серед яких інтерфейс KeyValueStore використовується для зберігання активних даних, що часто змінюються, таких як останній блок, стан тощо. AncientStore використовується для обробки історичних фрагментів даних, які рідко змінюються після написання.
// Топ-інтерфейс бази даних типу Database інтерфейс { KeyValueStore AncientStore}// Інтерфейс читання та запису KV даних типу KeyValueStore інтерфейс { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee Compacter io.Closer}// Інтерфейс для обробки старих даних читання та запису типу AncientStore інтерфейс { AncientReader AncientWriter AncientStater io.Closer}
EVM
EVM є функцією перетворення стану цього станового автомата Ethereum, всі оновлення стану даних можуть здійснюватися лише через EVM, p2p мережа може отримувати інформацію про транзакції та блоки, ця інформація після обробки EVM стане частиною бази даних стану. EVM приховує різницю між підключеним апаратним забезпеченням, що дозволяє програмам отримувати однакові результати при виконанні на різних платформах EVM. Це дуже зріла дизайнерська концепція, аналогічний дизайн існує також у Java мові, де JVM виконує подібну функцію.
Існування EVM має три основні компоненти: структура EVM, визначена в core/vm/evm.go, визначає загальну структуру EVM та залежності, включаючи контекст виконання, залежності від бази даних стану тощо; структура EVMInterpreter, визначена в core/vm/interpreter.go, реалізує інтерпретатор, відповідальний за виконання EVM байт-коду; структура Contract в core/vm/contract.go інкапсулює конкретні параметри виклику контракту, включаючи викликувача, код контракту, вхідні дані тощо, а також у core/vm/opcodes.go визначено всі поточні кодові операції:
EVMtype EVM struct { // Контекст блоку, що містить інформацію, пов'язану з блоком Context BlockContext // Контекст транзакції, що містить інформацію, пов'язану з транзакцією TxContext // База даних станів, що використовується для доступу та зміни стану облікового запису StateDB StateDB // Глибина поточного виклику int // Параметр конфігурації ланцюжка chainConfig *params. ChainConfig chainRules параметри. Rules // EVM Config Config // Інтерпретатор байт-коду *EVMInterpreter // Перервати прапор виконання abort atomic. Bool callGasTemp uint64 // прекомпілює map[common. Address]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // Вказати на екземпляр EVM, до якого він належить evm *EVM // Таблиця переходів коду операції *JumpTable // Кешер екземпляр Keccak256, обмінюватися хешер-крипто між кодами операцій. KeccakState // Keccak256 хеш-результат буфер hasherBuf загальний. Hash // Незалежно від того, чи це режим тільки для читання, модифікація стану не допускається в режимі тільки читання readOnly bool // Для подальшого повторного використання використовуються дані останнього CALL returnData []byte }type Contract struct { // адреса абонента caller common. Адреса // Адреса контракту загальна. Карта стрибків адрес[загальна. Hash]bitvec аналіз bitvec // Контракт Байт-код Код []байт // Код хеш CodeHash загальний. Hash // Call input []byte // Чи розгортати булеве значення IsDeployment для контракту // Чи викликати булеве значення IsSystemCall // Доступний газовий газ uint64 // Кількість ETH, прикріплена до значення виклику *uint256. Int }
Інші модулі реалізації
Функції виконавчого рівня реалізуються за допомогою багаторівневої структури, а інші модулі та функції побудовані на основі цих трьох основних компонентів. Тут представлено кілька основних модулів.
У eth/protocols є реалізація поточних підпротоколів p2p мережі Ethereum. Є підпротоколи eth/68 і snap, які побудовані на devp2p.
eth/68 є основним протоколом Ethereum, назва протоколу - це eth, 68 - його номер версії, а на основі цього протоколу реалізовані такі функції, як пул транзакцій (TxPool), синхронізація блоків (Downloader) та синхронізація транзакцій (Fetcher). Протокол snap використовується для швидкої синхронізації блоків та стану даних, коли нова нода приєднується до мережі, що може значно зменшити час запуску нової ноди.
ethdb надає можливості читання та запису для бази даних на нижньому рівні. Оскільки в протоколі Ethereum є багато складних структур даних, безпосередньо через ethdb неможливо реалізувати управління цими даними, тому на ethdb були реалізовані rawdb та statedb для окремого управління блоками та станом даних.
EVM пронизує всі основні процеси, незалежно від того, чи це побудова блоку, чи верифікація блоку, все одно потрібно використовувати EVM для виконання транзакцій.
05\Geth Нода запуск процесу
Запуск Geth поділиться на два етапи: перший етап ініціалізує компоненти та ресурси, необхідні для запуску Ноди, другий етап офіційно запустить Ноду, а потім надасть зовнішні послуги.
Нода ініціалізації
При запуску ноди geth будуть задіяні такі коди:
Ініціалізація кожного модуля виглядає так:
Ініціалізація Ноди буде виконана в makeFullNode у файлі cmd/geth/config.go, з акцентом на ініціалізацію наступних трьох модулів.
На першому етапі буде ініціалізовано структуру Node у node/node.go, яка є всім контейнером ноди, всі функції повинні виконуватись у цьому контейнері. На другому етапі буде ініціалізовано структуру Ethereum, яка включає реалізацію різноманітних основних функцій Ethereum. Etherereum також потрібно зареєструвати в Node. Третій етап полягає в реєстрації Engine API в Node.
Ініціалізація Нода полягає у створенні екземпляра Нода, а також у ініціалізації p2p сервера, управління обліковими записами та http тощо, що надаються зовнішнім протоколам.
Ініціалізація Ethereum буде набагато складнішою, більшість основних функцій ініціалізуються тут. По-перше, ініціалізується ethdb та завантажується конфігурація ланцюга зі сховища, потім створюється консенсусний двигун, який не виконує операції консенсусу, а лише перевіряє результати, що повертаються консенсусним шаром. Якщо в консенсусному шарі виникає запит на виведення, фактична операція виведення також виконується тут. Потім ініціалізується структура блокчейну та пул транзакцій.
Як тільки це зроблено, ініціалізується обробник, який є точкою входу для всіх запитів мережі P2P, включаючи синхронізацію транзакцій, завантаження блоків тощо, і є ключовим компонентом децентралізованої роботи Ethereum. Після того, як вони будуть завершені, деякі підпротоколи, реалізовані на основі devp2p, такі як eth/68, snap тощо, будуть зареєстровані в контейнері Node, і, нарешті, Ethereum буде зареєстровано як життєвий цикл у контейнері Node, а ініціалізація Ethereum буде завершена.
Врешті-решт ініціалізація Engine API є відносно простою, просто зареєструвати Engine API в Ноді. На цьому етапі ініціалізація вузла повністю завершена.
Нода запуску
Після завершення ініціалізації Ноди необхідно запустити Ноду. Процес запуску Ноди відносно простий: потрібно лише запустити всі зареєстровані RPC-сервіси та Lifecycle, після чого вся Нода зможе надавати послуги зовнішньому світу.
06\резюме
Перш ніж глибше зрозуміти реалізацію виконавчого рівня Ethereum, необхідно мати загальне уявлення про Ethereum. В цілому Ethereum можна розглядати як транзакційно-орієнтовану машину станів, де виконавчий рівень відповідає за виконання транзакцій та зміни стану, а рівень консенсусу відповідає за управління роботою виконавчого рівня, включаючи створення блоків, визначення порядку транзакцій, голосування за блоки та надання блокам остаточності. Оскільки ця машина станів є децентралізованою, необхідно спілкуватися з іншими Нода через p2p мережу для спільного підтримання узгодженості стану даних.
Виконавчий рівень не відповідає за визначення порядку транзакцій, а лише за виконання транзакцій та запис змін стану після виконання транзакцій. Записи тут мають два формати: один - це блоковий формат, в якому всі зміни стану записуються, інший - це запис поточного стану в базі даних. Водночас виконавчий рівень є входом для транзакцій, зберігаючи ще не упаковані в блок транзакції в пулі транзакцій. Якщо інші ноди потребують отримати дані про блоки, стан та транзакції, виконавчий рівень через p2p мережу надсилає цю інформацію.
Для виконавчого рівня є три основні модулі: обчислення, зберігання та мережа. Обчислення відповідає реалізації EVM, зберігання відповідає реалізації ethdb, а мережа відповідає реалізації devp2p. Маючи таке загальне розуміння, можна глибше зрозуміти кожен підмодуль, не гублячись у конкретних деталях.
07\Посилання
[1]
[2]
[3]
[4]
[5]
[6]
· КІНЕЦЬ·
Зміст | Ray
Редагування & Верстка | Хуан Хуан
Дизайн | Daisy