Здравствуйте, мы EOSeul, кандидат технических блоков из Кореи.
Сегодня мы рады объявить «CODEOS», курс разработки EOSeul, где вы можете узнать все о разработке EOS. Мы потратили последние пару месяцев на создание учебных материалов с нуля с конечной целью обеспечить, чтобы мы дали сообществу наилучшую возможную основу.

CODEOS призван развивать глобальную экосистему блокчейнов, преодолевая пробелы в знаниях EOS и поддерживая разработчиков EOS. Сегодня мы собираемся раскрыть основные знания по разработке контрактов EOS. Эта статья представляет собой краткое изложение основных понятий, и мы рассмотрим каждое понятие более подробно в следующих статьях.

В настоящее время безопасность очень важна, и ей следует уделять первостепенное внимание. Блокчейн становится очень интересным, и кажется, что его может легко адаптировать любой человек. Открытый исходный код программирования блокчейна заставляет всех учиться, и многие все больше интересуются другими проектами и взламывают их.

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

Счет

Аккаунт, как правило,

  • без смарт-контракта
  • со смарт-контрактом

Учетная запись без контракта — это обычная учетная запись EOS для использования службы Dapp, такой как игры, токены для ставок, передача токенов и т. д.

Учетная запись со смарт-контрактами. Чтобы предоставлять услуги Dapp, вам необходимо создать учетную запись со смарт-контрактом. Учетная запись eosio.token имеет действие eosio.token для управления токенами. Таким образом, контракт токена предоставляет пользователям возможность создавать токены, выдавать токены и передавать токены.

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

1аккаунт : 1контракт

Каждый смарт-контракт EOSIO настроен на одну учетную запись EOSIO. Контракт — это, по сути, объект, с которым могут взаимодействовать другие учетные записи. Аккаунт не может иметь более 1 контракта.

Зарегистрироваться

Формат создания аккаунта в клеосе

$ cleos create account eosio NEW_ACCOUNT OWNER_KEY ACTIVE_KEY
Эта команда предназначена в основном для частной тестовой сети. Эта команда используется только для практических целей и не связана с реальной цепочкой блоков. Но когда разработчики работают с реальным блокчейном, используется общедоступная тестовая сеть или общедоступная основная сеть. Чтобы создать учетную запись в общедоступной тестовой сети или основной сети, выполните следующую команду.

$cleos system newaccount [OPTIONS] creator name OwnerKey [ActiveKey]

создатель: имя учетной записи, создающей новую учетную запись (обязательно)
name : имя новой учетной записи (обязательно)
OwnerKey: открытый ключ владельца для новой учетной записи (обязательно)
ActiveKey: активный открытый ключ для новой учетной записи
[Параметры] больше касаются ставок, покупки оперативной памяти, разрешений, максимального использования сети, времени задержки и т. д.

Это объясняет, что учетная запись защищена как ключом владельца, так и активным ключом. Нам всегда нужно сохранять ключи в отдельном личном документе для последующего использования. Новичкам рекомендуется использовать активную клавишу для всех действий, которые мы делаем, пока вы полностью не поймете концепции.

Действия EOS

Существует два типа вызова действия EOS: внешнее и встроенное действие.

1) Внешние действия

: внешние действия происходят, когда пользователь вызывает действие непосредственно извне.

2) Встроенные действия

  • Тип 1: встроенные действия происходят, когда действие вызывает другое действие в том же контракте.
  • Тип 2: встроенные действия происходят, когда действие вызывает другое действие во внешнем контракте.

Здесь мы использовали пример адресной книги и абкаунтера в портале разработчиков eosio в разделе 2.6 и 2.7

Давайте рассмотрим каждый тип встроенных действий.

Тип 1 Разрешения для встроенных действий:

В этом при реализации "push action" вышла ошибка!
$cleos push action addressbook upsert '["sriaccount11", "Marc","Albert", "flat 603 city apt", "small city", "USA"]' -p sriaccount11@active

Error 3090003: Provided keys, permissions, and delays do not satisfy declared authorizations
Ensure that you have the related private keys inside your wallet and your wallet is unlocked.

Встроенные действия типа 2 для внешнего контракта

Эта ошибка типа 1 возникает и в случае действия типа 2. Встроенные действия могут выполняться только с разрешения eosio.code, поэтому для исправления этой ошибки требуется разрешение eosio.code.
Если хотите узнать, как проверить авторизацию встроенных действий, нажмите здесь!

eosio.code

eosio.code — это виртуальный центр кода, который повышает безопасность и позволяет контрактам выполнять встроенные действия.
Чтобы получить разрешения, eosio.code необходимо добавить в собственную учетную запись контракта. Ниже показано изображение, объясняющее, что происходит после добавления eosio.code.

Итак, для этого необходимо запустить следующий код:
$cleos set account permission addressbook active '{"threshold": 1,"keys": [{"key": "YOUR_PUBLIC_KEY","weight": 1}], "accounts": [{"permission":{"actor":"addressbook","permission":"eosio.code"},"weight":1}]}' -p addressbook@owner

Чтобы встроенные действия могли взаимодействовать в контракте или с внешним контрактом, встроенные действия требуют разрешений и авторизаций учетной записи контракта владельца.

Чтобы узнать более подробно или узнать больше о других возможностях разрешений, мы можем увидеть по этой следующей ссылке на странице разработчика Eos.
«https://developers.eos.io/eosio-cleos/reference#cleos-set -Счет"

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

Разрешение

Разрешения в основном состоят из ключа владельца или активного ключа. Существует три типа весов: ключи, счета и ожидания.

Для управления учетной записью использование имени учетной записи проще и интуитивно понятнее, чем использование открытых ключей, которые трудно запомнить. Как мы уже упоминали о eosio.code, в этом случае вы должны использовать тип веса аккаунта.

Формат разрешений

В приведенном выше примере мы также можем заметить, что в учетных записях есть 2 разрешения, что означает, что одна учетная запись может разрешать одну или несколько учетных записей. Это понятие Multisig.

Аккаунт с мультиподписью

В этом еще одном небольшом примере мы объясним, как работает мультиподписной кошелек и как его настроить самостоятельно.

Взято из EOSIO Wiki

В этом примере разрешение владельца имеет пороговое значение 2 и имеет 2 ключа, оба с весом 1. Это означает, что подпись обоих ключей необходима для выполнения любого действия, требующего разрешения владельца.
активное разрешение имеет порог 1 и имеет 2 ключа, оба с весом 1. Это означает, что для выполнения любого действия, требующего активного разрешения, требуется только 1 подпись любого из 2 ключей.

Ожидания: ожидание позволяет пользователю гарантировать, что транзакция не может быть выполнена без требуемой
задержки. Чтобы указать ожидание в EOS, вы должны указать wait_sec и вес задержки.

Разрешения являются очень важной частью взаимодействия.

  • Они улучшают безопасность
  • Планированием транзакций также можно управлять с помощью весов и порогов.

Уведомление

При использовании встроенного действия вам необходимо добавить разрешение «[email protected]» в учетную запись пользователя. Однако подать заявку на сервис непросто, поскольку большинство пользователей неохотно добавляют его в свою учетную запись. Таким образом, функция уведомления используется в основном в сервисе, а не для добавления разрешения.

Уведомление – это функция, которая доставляет назначенному пользователю действие об успешном выполнении после его успешного завершения.
Когда действия выполняются в рамках контрактов или с использованием внешних контрактов, существует очень полезный способ проверить, правильно ли они выполнены, путем получения уведомление. eosio.token — хороший пример, чтобы понять, как выполняются действия по передаче и как делается уведомление.

Здесь,

require_auth(имя учетной записи)
Это действие объясняет, что функция передачи требует авторизации владельца учетной записи, с которой передаются токены.

require_recipient (имя учетной записи)

Это действие помогает получить уведомление на учетную запись. Это объясняет, что текущее действие должно быть доставлено на имя учетной записи.

Обработчики действий

«Макрос EOSIO_DISPATCH» и «применить функцию»:
Есть также несколько очень важных моментов, о которых необходимо помнить.

Каждый смарт-контракт должен предоставлять обработчик действия применения или «диспетчер». Диспетчер — это функция, которая слушает все входящие действия и выполняет желаемое поведение. Эти диспетчеры выполнены в виде небольших макросов.

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

#define EOSIO_DISPATCH( eosio::bios, (setpriv)(setalimits)(setglimits)(setprods)(reqauth) )

#define EOSIO_DISPATCH( TYPE, MEMBERS ) extern "C" { void apply( uint64_t receiver, uint64_t code, uint64_t action ) { if( code == receiver ) { switch( action ) { EOSIO_DISPATCH_HELPER( TYPE, MEMBERS ) } // does not allow destructor of thiscontract to run: eosio_exit(0); } } }

Чтобы ответить на определенное действие, требуется код для идентификации и ответа на запросы определенных действий. apply использует входные параметры приемника, кода и действия в качестве фильтров для сопоставления с нужными функциями, которые реализуют определенные действия.

Иногда код мог быть «самим собой» или «получателем» в зависимости от необходимости. Мы также можем сделать собственный макрос, который может учитывать наши потребности однозначно. они полностью зависят от типа транзакции по счету (встроенная или отложенная).

Функция применения может фильтровать параметр кода, используя что-то вроде следующего.

Чтобы ответить на определенное действие, требуется код для идентификации и ответа на запросы определенных действий. apply использует входные параметры приемника, кода и действия в качестве фильтров для сопоставления с нужными функциями, которые реализуют определенные действия.

Иногда код мог быть «самим собой» или «получателем» в зависимости от необходимости. Мы также можем создать пользовательский макрос, который может учитывать наши потребности уникальным образом.
Функция применения может фильтровать параметр кода, используя что-то вроде следующего
if (code == name("contract_name").value) { // your handler to respond to particular code }

Функция применения может фильтровать параметр действия, используя что-то вроде следующего
if (action == name("action_name").value) { // your handler to respond to particular action }
Функция применения может фильтровать параметр действия, используя что-то вроде следующего

if (code==self) { // can make some upserts, updates, erase, notify to its own actions. }

Функция применения может фильтровать параметр действия, используя что-то вроде следующего
if (code==receiver) { switch(action) { // does not allow the dispatcher of this contract to run: eosio_exit(0); } }

В следующей статье обработчики действий будут рассмотрены более подробно.

Прошлые взломанные проблемы:

Взлом также был возможен из-за условий, которые они применяли для прикладного кода. Вот несколько примеров:

В Tokens 24 говорится, что 9 сентября пользователь DEOS Game под названием runningsnail неоднократно получал платежи в размере 1000 долларов после внесения 10 EOS и выигрывал джекпот всего через несколько секунд. 10 сентября они подтвердили, что это был взлом.

ЗАЯВЛЕНИЕ О ВЗЛОМЕ EOS BET TRANSFER, написанное казино EOS Bet 15 сентября, смарт-контракт был взломан, что привело к значительной потере средств. Ошибка была в экспедиторе ABI. Это позволяет контракту принимать каждый доход токена eosio и любую возможность действия со смарт-контрактом.

Аналогично это происходит и с EOS Knights. Eos Knights также опубликовали 14 сентября, что они столкнулись с подобным взломом. Но, к счастью, до того, как злоумышленник взломал систему, их Prospectors.io сообщил о проблеме и эвакуировал свой EOS в безопасную учетную запись.

Вывод:

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

Authorities
Permissions
eosio.code
Notification
require_auth
require_recipient
Dispatchers

Спасибо.

Команда EOSeul.

Контакты EOSeul

Telegram
Facebook
Youtube
Medium
Steemit
Github
Twitter
Биху