Доп 2. Стандарты EIP, ERC
Предложения по усовершенствованию Ethereum (EIPs)
Репозиторий Ethereum Improvement Proposal находится по адресу github.com/ethereum/EIPs. Рабочий процесс проиллюстрирован в документе "Рабочий процесс предложения по улучшению Ethereum".
Из EIP-1: EIP расшифровывается как Ethereum Improvement Proposal. EIP - это проектный документ, предоставляющий информацию сообществу Ethereum или описывающий новую функцию для Ethereum, его процессов или среды. EIP должен содержать краткую техническую спецификацию функции и ее обоснование. Автор EIP отвечает за достижение консенсуса в сообществе и документирование особых мнений.
Рисунок 1. Рабочий процесс предложения по улучшению Ethereum
Таблица наиболее важных EIP и ERC
Таблица 1. Важные EIP и ERC
| EIP/ERC # | Title/Description |
|---|---|
| EIP-1 | Цель и руководящие принципы EIP |
| EIP-2 | Изменения, связанные с хард-форком |
| EIP-5 | Gas Usage for RETURN and CALL* |
| EIP-6 | Renaming +SUICIDE+ Opcode |
| EIP-7 | DELEGATECALL |
| EIP-8 | devp2p Forward Compatibility Requirements for Homestead |
| EIP-20 | ERC-20 Token Standard. Describes standard functions a token contract may implement to allow DApps and wallets to handle tokens across multiple interfaces/DApps. Methods include: totalSupply, +balanceOf(address)+, transfer, transferFrom, approve, allowance. Events include: Transfer (triggered when tokens are transferred), pass:[Approval] (triggered when approve is called). |
| EIP-55 | Кодирование адреса контрольной суммы в смешанном регистре |
| EIP-86 | Абстракция происхождения и подписи транзакций. Закладывает основу для "абстрагирования" безопасности аккаунта и позволяет пользователям создавать "контракты аккаунта", двигаясь к модели, в которой в долгосрочной перспективе все счета являются контрактами, которые могут оплачивать газ, и пользователи могут свободно определять свои собственные модели безопасности, которые выполняют любую желаемую проверку подписи и проверку nonce (вместо использования внутрипротокольного механизма, где ECDSA и схема nonce по умолчанию являются единственным "стандартным" способом защиты аккаунта, который в настоящее время жестко закодирован в обработке транзакций). |
| EIP-96 | Изменения корня блокхэша и состояния. Хранит блокхеши в состоянии, чтобы уменьшить сложность протокола и необходимость в сложных клиентских реализациях для обработки опкода BLOCKHASH. Расширяет диапазон того, как далеко назад может уходить проверка блокчейна, с побочным эффектом создания прямых связей между блоками с очень удаленными номерами блоков для более эффективной начальной синхронизации клиентов. |
| EIP-100 | Изменить настройку сложности на целевое среднее время блока и включение дядек. |
| EIP-101 | Валюта спокойствия и криптовалюта абстракции. Абстрагирует эфир на более высокий уровень, позволяя эфиру и субтокенам одинаково обращаться с контрактами, снижает уровень косвенности, необходимый для пользовательских политик, таких как мультисиги, и очищает основной протокол Ethereum, снижая минимальную сложность реализации консенсуса. |
| EIP-105 | Бинарный шардинг плюс семантика вызова контрактов. "Лесенка для шардинга" EIP, позволяющая распараллеливать транзакции Ethereum с помощью механизма шардинга двоичного дерева и создающая основу для последующей схемы шардинга. Исследования в процессе; см. https://github.com/ethereum/sharding[]. |
| EIP-137 | Служба доменных имен Ethereum - спецификация |
| EIP-140 | Новый опкод: +REVERT+. Добавляет опкод REVERT, который останавливает выполнение и откатывает изменения состояния выполнения EVM без потребления всего предоставленного газа (вместо этого контракт должен платить только за память) или потери логов, и возвращает вызывающей стороне указатель на участок памяти с кодом ошибки или сообщением. |
| EIP-141 | Designated invalid EVM instruction |
| EIP-145 | Инструкции побитового сдвига в EVM |
| EIP-150 | Изменение стоимости газа для операций с большим объемом ввода-вывода |
| EIP-155 | Простая защита от атаки повторного воспроизведения. Атака повторного воспроизведения позволяет любой транзакции, использующей узел или клиент Ethereum до EIP-155, стать подписанной, чтобы она была действительной и выполнялась как в цепочке Ethereum, так и в Ethereum Classic. |
| EIP-158 | Государственный клиринг |
| EIP-160 | Увеличение стоимости EXP |
| EIP-161 | Расчистка тройки штатов (инвариантно-сохраняющая альтернатива) |
| EIP-162 | Начальный регистратор хэша ENS |
| EIP-165 | Обнаружение стандартного интерфейса ERC-165 |
| EIP-170 | Ограничение размера кода контракта |
| EIP-181 | Поддержка ENS для обратного разрешения адресов Ethereum |
| EIP-190 | Стандарт упаковки смарт-контрактов Ethereum |
| EIP-196 | Предварительно скомпилированные контракты для сложения и скалярного умножения на эллиптической кривой +alt_bn128+. Требуется для выполнения верификации zkSNARK в пределах лимита блочного газа. |
| EIP-197 | Предварительно скомпилированные контракты для оптимальной проверки парности на эллиптической кривой +alt_bn128+. Объединен с EIP-196. |
| EIP-198 | Большая целочисленная модульная экспоненция. Прекомпиляция, позволяющая проверять подпись RSA и другие криптографические приложения. |
| EIP-211 | Новые опкоды: RETURNDATASIZE и RETURNDATACOPY. Добавляет поддержку возврата значений переменной длины внутри EVM с простым газовым зарядом и минимальными изменениями в вызывающих опкодах, используя новые опкоды RETURNDATASIZE и RETURNDATACOPY. Обработка аналогична существующей calldata, при которой после вызова возвращаемые данные сохраняются в виртуальном буфере, из которого вызывающая сторона может скопировать их (или их части) в память, а при следующем вызове буфер перезаписывается. |
| EIP-214 | Новый опкод: STATICCALL. Разрешает не изменяющие состояние вызовы самого себя или других контрактов, запрещая любые изменения состояния во время вызова (и его подвызовов, если они есть), чтобы повысить безопасность смарт-контракта и гарантировать разработчикам, что ошибки реентерабельности не могут возникнуть в результате вызова. Вызывает дочерний контракт с флагом STATIC, установленным в true для выполнения дочернего контракта, вызывая исключение при любых попытках выполнить операции по изменению состояния внутри экземпляра выполнения, где STATIC равен true, и сбрасывает флаг после возвращения вызова. |
| EIP-225 | Rinkeby testnet, использующий доказательство полномочий, где блоки добываются только доверенными подписчиками. |
| EIP-234 | Добавить blockHash в опции фильтра JSON-RPC |
| EIP-615 | Подпрограммы и статические переходы для EVM |
| EIP-616 | SIMD-операции для EVM |
| EIP-681 | Формат URL для транзакционных запросов |
| EIP-649 | Metropolis Задержка бомбы сложности и уменьшение награды за блок. Задержка Ледникового периода (он же Бомба сложности) на 1 год и снижение награды за блок с 5 до 3 эфиров. |
| EIP-658 | Встраивание кода статуса транзакции в квитанции. Находит и встраивает поле статуса, указывающее на состояние успеха или неудачи, в квитанции транзакции для вызывающих, так как больше нельзя считать, что транзакция не удалась, если и только если она израсходовала весь газ после введения опкода REVERT в EIP-140. |
| EIP-706 | DEVp2p snappy compression |
| EIP-721 | ERC-721 Non-Fungible Token Standard. Стандартный API, позволяющий смарт-контрактам работать в качестве уникальных торгуемых нефункциональных токенов (NFT), которые можно отслеживать в стандартизированных кошельках и торговать на биржах как ценные активы, аналогично ERC20. CryptoKitties стал первой популярной реализацией цифрового NFT в экосистеме Ethereum. |
| EIP-758 | Подписки и фильтры для завершенных транзакций |
| EIP-801 | ERC-801 Canary Standard |
| EIP-827 | ERC827 Token Standard. Расширение стандартного интерфейса ERC20 для токенов с методами, позволяющими выполнять вызовы внутри +передача+ и утверждения. Этот стандарт предоставляет базовую функциональность для передачи токенов, а также позволяет одобрить токены, чтобы они могли быть потрачены другой третьей стороной на цепочке. Кроме того, он позволяет разработчику выполнять вызовы по переводам и утверждениям |
| EIP-930 | ERC930 Вечное хранение. Контракт ES (Eternal Storage) принадлежит адресу, который имеет права на запись. Хранилище является общедоступным, что означает, что все имеют права на чтение. Оно хранит данные в отображениях, используя одно отображение для каждого типа переменных. Использование этого контракта позволяет разработчику при необходимости легко перенести хранилище на другой контракт |