Full Chain Game 101: попередньо скомпільовані контракти

**Що таке попередньо скомпільований контракт? **

Попередньо скомпільовані контракти — це компромісний метод, який використовується в EVM для надання більш складних бібліотечних функцій (зазвичай використовується для складних операцій, таких як шифрування та хешування). Його також можна розуміти як спеціальний контракт, і ці функції не підходять для написання кодів операцій. Вони підходять для контрактів, які є простими, але часто викликаються, або контрактів, які є логічно фіксованими, але потребують інтенсивних обчислень. Попередньо скомпільовані контракти реалізуються за допомогою клієнтського коду вузла, і оскільки для них не потрібен EVM, вони працюють швидко. Це також дешевше для розробника, ніж використання функцій, які запускаються безпосередньо в EVM.

Як видно з наведеного нижче коду, функція run у контракті evm.go має дві гілки: перша гілка призначена для створення екземпляра параметра індексу через попередньо скомпільований індекс для визначення попередньо скомпільованого контракту, а друга гілка призначена для визначення попередньо скомпільованого контракт, якщо це не попередньо скомпільований контракт, який буде викликано evm.

// run запускає заданий контракт і піклується про запуск попередніх компіляцій із поверненням до інтерпретатора байтового коду. func run(evm *EVM, contract *Contract, input []byte, readOnly bool) ([]byte, error) { if contract.CodeAddr != nil { precompiles := PrecompiledContractsHomestead if evm.ChainConfig().IsByzantium(evm.BlockNumber) { precompiles = PrecompiledContractsByzantium } if p := precompiles[*contract.CodeAddr]; p != nil { return RunPrecompiledContract(p, input, contract) } } для _, інтерпретатор := діапазон evm.interpreters { if interpreter.CanRun(contract.Code) { if evm.interpreter != інтерпретатор { // Переконайтеся, що покажчик інтерпретатора встановлено назад // до поточного значення після повернення. defer func(i Інтерпретатор) { evm.interpreter = i }(evm.інтерпретатор) evm.interpreter = інтерпретатор } return interpreter.Run(contract, input, readOnly) } } повертає нуль, ErrNoCompatibleInterpreter }

Якщо висловити графічно, то конкретна логіка така:

Отже, де вузьке місце попередньо скомпільованого контракту?

Зараз Ethereum має вісім попередньо скомпільованих контрактів:

1. ECRecover - Відновити відповідну адресу за допомогою підпису
2. SHA256 - обчислити хеш SHA256
3. RIPEMD160 - обчислює хеш RIPEMD160
4. Ідентичність - повертає вихідне значення вхідних даних
5. ModExp - виконує піднесення до степеня за модулем
6. ECAdd - додавання точок еліптичної кривої
7. ECMul - множення точок еліптичної кривої
8. ECPairing - операція сполучення, перевірка точок еліптичної кривої

Ви бачите, що попередньо скомпільовані контракти з першого по четвертий забезпечують базовий підпис, хеш та інші функції шифрування, а з п’ятого по восьмий надають операції еліптичної кривої, пов’язані з zk-snark.

Тож виникає запитання: чому попередня компіляція Ethereum підтримує лише вісім попередньо скомпільованих контрактів? Хіба попередньо скомпільовані контракти не зменшують споживання газу? А чому б безпосередньо не імплантувати ECS (фреймворк цілої ланцюжкової гри) у попередньо скомпільований контракт Ethereum?

Насправді є три основні причини:

1. Надмірна залежність від попередньо скомпільованих контрактів зменшить ступінь децентралізації всієї платформи:

Перш за все, код попередньо скомпільованого контракту потрібно інтегрувати в код клієнтського вузла, що збільшує складність клієнта. По-друге, верифікаційні вузли можуть відфільтрувати розрахунок попередньо скомпільованих контрактів з міркувань безпеки, тому більшість запитів на попередньо скомпільовані контракти виконуються повними вузлами.Наразі у світі існує лише 4000-6000 повних вузлів Ethereum, а верифікаційних – 500 000 вузлів, що справді є набагато більш централізованим, ніж некомпільовані контракти.

2. Додавання та модифікація попередньо скомпільованих контрактів вимагає оновлень хардфорка, які нелегко розвивати гнучко.

Для підтримки попередньо скомпільованих контрактів потрібен процес EIP. Наприклад: EIP-196 додає два попередньо скомпільовані контракти, ECADD() і ECMUL(), на кривій alt_bn128. EIP-197 додає функцію сполучення на кривій alt_bn128. По суті, це зробити конфіденційність доступною в Ethereum для підтримки, а весь процес EIP довгий і елегантний, і очікування проходження EIP не є реальною проблемою.

3. Важко взаємодіяти та поєднувати попередньо скомпільовані контракти, а також погана масштабованість.

Це не так багато для пояснення, це дуже інтуїтивно зрозуміло.

Яку роль відіграє попередньо скомпільований контракт у всій ланцюжковій грі?

Попередньо скомпільовані контракти пропускають EVM і виконуються безпосередньо через вузли, що може підвищити ефективність обчислень, але в той же час знизити ступінь децентралізації всього ланцюжка. Попередня компіляція основної логіки часто використовуваних ігор може оптимізувати продуктивність таких ігор. Різні типи ігор мають різну ключову логіку. Таким чином, для виділеного ланцюжка певного типу гри його попередньо скомпільований дизайн може значно оптимізувати потреби цього типу гри. У процесі ітерації гри найефективніша попередньо скомпільована комбінація контрактів буде поступово оптимізована.