В «Желтой книге» говорится:
Это четыре так называемых «предварительно скомпилированных» контракта, задуманных как предварительная часть архитектуры, которая впоследствии может стать собственными расширениями. Четыре контракта по адресам 1, 2, 3 и 4 выполняют функцию восстановления открытого ключа эллиптической кривой, 256-битную хеш-схему SHA2, 160-битную хеш-схему RIPEMD и функцию идентификации соответственно.
Что такое предварительно скомпилированный контракт и чем он отличается от нативных кодов операций? Если предварительно скомпилированный контракт станет нативным расширением, что он получит? Учитывая широкое распространение SHA2-256, почему он не был реализован изначально?
Хоть я и не знаю настоящей причины, но попытаюсь угадать. Будут следующие соображения:
Размер пространства имен . Возможных кодов операций не так много, поэтому их нужно выделять очень экономно. С другой стороны, пространство контрактных адресов практически не ограничено для всех практических целей.
Риск повторного использования имени . Не использовать повторно имена (или коды операций) — хороший принцип разработки программного обеспечения, особенно в системе, где никто не контролирует обновления.
Утилита . Есть некоторые операции, которые всегда полезны, такие как арифметические операции, перестановка битов, управление потоком и другие. Криптографические примитивы, с другой стороны, в будущем могут оказаться неадекватными, и вместо них будет использоваться что-то другое. Превращая такие примитивы в коды операций, вы рискуете потратить ценное пространство имен на что-то, что может устареть.
Мягкое продвижение популярного/полезного кода . Если определенные вещи, например, операции zkSNARKs или проверка Dogecoin PoW, начиная с кода солидности, а затем частично оптимизированные, станут очень полезными и популярными, они могут стать предварительно скомпилированными контрактами. Такое продвижение — гораздо более мягкое изменение сети, чем введение нового опкода.
Не авторитет, но я знаю кое-кого, кто...
Из статьи Виталика « Предыстория протокола Ethereum ».
Второй была идея «прекомпиляции», решая проблему, позволяющую использовать сложные криптографические вычисления в EVM без необходимости иметь дело с накладными расходами EVM. Мы также рассмотрели много более амбициозных идей о «нативных контрактах», где, если майнеры имеют оптимизированную реализацию некоторых контрактов, они могут «проголосовать» за газцену этих контрактов, поэтому контракты, которые большинство майнеров могли бы выполнять намного быстрее, естественно, имели бы более низкая цена на газ; однако все эти идеи были отвергнуты, потому что мы не могли придумать криптоэкономически безопасный способ реализации такой вещи. Злоумышленник всегда может создать контракт, который выполняет какую-то криптографическую операцию с лазейкой, распространить лазейку на себя и своих друзей, чтобы они могли выполнять этот контракт намного быстрее, затем проголосуйте за понижение цены на газ и используйте это для DoS-атак в сети. Вместо этого мы выбрали гораздо менее амбициозный подход с меньшим количеством предварительных компиляций, которые просто указаны в протоколе для общих операций, таких как хэши и схемы подписи.
Я не думаю, что есть «правильный ответ» на вопрос, должна ли какая-либо данная функциональность быть предварительной компиляцией или нативной. Похоже, что по всем причинам, изложенным ранее, все сводилось к дизайнерскому суждению. Если сами VB или gavofyork не вмешаются, мы никогда не узнаем наверняка...
Т9б