Полная цепочка игр 101: Предварительно скомпилированные контракты

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

Предварительно скомпилированные контракты — это компромиссный метод, используемый в EVM для предоставления более сложных библиотечных функций (обычно используется для сложных операций, таких как шифрование и хеширование), а также может пониматься как специальный контракт, не подходящий для написания опкодов. Они подходят для контрактов, которые просты, но часто вызываются, или контрактов, которые логически фиксированы, но требуют больших вычислительных ресурсов. Предварительно скомпилированные контракты реализуются с использованием кода клиента узла, и, поскольку им не требуется EVM, они работают быстро. Это также дешевле для разработчика, чем использование функций, которые запускаются непосредственно в EVM.

Как видно из следующего кода, функция запуска в контракте evm.go имеет две ветви: первая ветвь предназначена для создания экземпляра параметра index через предварительно скомпилированный индекс для указания предварительно скомпилированного контракта, а вторая ветвь — для указания предварительно скомпилированного контракт, если это не предварительно скомпилированный контракт. Будет вызван evm.

// run запускает данный контракт и заботится о запуске прекомпиляции с откатом к интерпретатору байт-кода. func run(evm *EVM, contract *Contract, input []byte, readOnly bool) ([]byte, error) { если contract.CodeAddr != ноль { прекомпиляции := PrecompiledContractsHomestead если evm.ChainConfig().IsByzantium(evm.BlockNumber) { прекомпиляции = PrecompiledContractsByzantium } if p := precompiles[*contract.CodeAddr]; р != ноль { вернуть RunPrecompiledContract (p, ввод, контракт) } } для _ интерпретатор := диапазон evm.interpreters { если интерпретатор.CanRun(contract.Code) { если evm.interpreter != интерпретатор { // Убедитесь, что указатель интерпретатора установлен обратно // к своему текущему значению после возврата. отложить функцию (интерпретатор) { evm.interpreter = я }(evm.интерпретатор) evm.interpreter = интерпретатор } вернуть интерпретатор. Выполнить (контракт, ввод, только для чтения) } } вернуть ноль, ErrNoCompatibleInterpreter }

Если выразить графически, конкретная логика выглядит следующим образом:

Так где же узкое место предварительно скомпилированного контракта?

В настоящее время Ethereum имеет восемь предварительно скомпилированных контрактов:

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

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

Итак, вопрос в том, почему прекомпиляция Ethereum поддерживает только восемь предварительно скомпилированных контрактов, разве прекомпилированные контракты не сокращают потребление газа? И почему бы напрямую не внедрить ECS (каркас всей цепной игры) в предварительно скомпилированный контракт Ethereum?

На самом деле основных причин три:

1. Чрезмерная зависимость от предварительно скомпилированных контрактов снизит степень децентрализации всей платформы:

Прежде всего, код предварительно скомпилированного контракта необходимо интегрировать в код клиентского узла, что увеличивает сложность клиента. Во-вторых, узлы проверки могут отфильтровывать расчет предварительно скомпилированных контрактов из соображений безопасности, поэтому большинство запросов на предварительно скомпилированные контракты выполняются полными узлами. узлов, что действительно гораздо более централизовано, чем некомпилированные контракты.

2. Добавление и изменение предварительно скомпилированных контрактов требует обновлений хард-форка, которые нелегко гибко развивать.

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

3. Трудно взаимодействовать и комбинировать предварительно скомпилированные контракты, а масштабируемость плохая.

Объяснять особо нечего, это очень интуитивно понятно.

Какую роль играет предварительно скомпилированный контракт во всей цепочке?

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