Как использовать прокси-платежи во время благотворительной кампании
Posted by Sergei Romanov 9 months ago

Дата публикации - 27 марта


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

Сказка о двух ролях

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

  1. Донор Боб начинает разговор с ботом, чтобы сообщить о своем намерении присоединиться к кампании. После подтверждения, бот раскрывает адрес смарт-контракта Бобу;
  2. Боб посылает определенное количество ETH на данный смарт-контракт;
  3. Смарт-контракт подтверждает донора, оплату и проксирует (уполномочивает) платеж по адресу благотворительности;
  4. Между тем, бот периодически извлекает транзакции из смарт-контракта и проверяет, прошли ли они;
  5. Если это так, бот награждает Боба очками и уведомляет его в Телеграмме.

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

Легкий способ получать платежи

Для обеспечения положительного опыта, процесс оплаты со смарт-контрактом должен быть как можно более простым — отправка ETH из любых кошельков/клиентов Эфириума без специальных операций. Чтобы это произошло, IoTeX использует резервную функцию, которая является единственной неназванной функцией в контракте и выполняется по требованию контракта, если ни одна из других функций не соответствует данной подписи функции. Мы используем его (показано ниже), после отправки платежа в контракт; выполняется функция резерва, которая в свою очередь вызывает donate () для выполнения работы.

Чтобы проксировать платежи на предназначенный адрес благотворительности, мы сначала попытались использовать функцию «charity.send ()», которая отлично работает, если благотворительная организация использует обычную учетную запись Эфириума. Но она не работает, если благотворительная организация использует контрактную учетную запись для получения пожертвований. Это объясняется тем, что «charity.send ()» является безопасной для повторного входа и выделяет только 2,300 газовых стипендий для следующего контракта, из-за чего у следующего контракта очень быстро заканчивается газ. Функция «charity.call.value ()» является правильным выбором в этой ситуации, поскольку она перенаправляет определенное количество газа в следующий контракт.

Несмотря на то что, функция «addr.call.value ()» более мощная, она небезопасна для повторного входа, и если используется неправильно, может легко привести к атаке (Reentrancy Attack), такой, как атака DAO в 2016 году. Альтернативы по безопасности: захватить мьютекс в функции, которая вызывает «addr.call.value ()», либо, мутировать внутренние состояния, например, обнулить баланс, прежде чем вызывать «addr.call.value ()». В нашем случае повторная атака не вызывает беспокойства, поскольку: а) наш смарт-контракт не имеет гражданства; б) мы используем адрес благотворительности, а не адрес отправителя. Кроме того, мы проверили аудит смарт-контракта для благотворительности, чтобы убедиться, что у него нет вредоносного кода.

Проверка доноров

«Все люди ошибаются», и контракт должен проверять действия наших доноров. Контракт разработан для подтверждения каждого платежа, таким образом:

  • Предотвратить доноров, не зарегистрированных в вайт листе; например, мы импортировали ~ 2,600 одобренных адресов в контракт и только для них платежи разрешены;
  • Предотвратить доноров делать платежи в неправильное время; например, контракт открывается только в определенный период времени 3/20/2018 5РМ PDT — 3/21/2018 5PM PDT;
  • Предотвратить доноров от пожертвования непредвиденной суммы; например, договор принимает только платеж >= 0.2ETH и <= 1.0ETH и отклоняет все остальные;
  • Предотвратить получение платежей от слишком большого числа доноров; например, мы ограничили число доноров до 2,600.

Кроме того, мы встроили пару функций для администраторов в смарт-контракт, а именно pause () и unpause (), которые могут остановить смарт-контракт от получения платежей в случае возникновения проблем или непредвиденных ситуаций, а также, возобновить его при необходимости.

В целом подтверждение пожертвований кодируется следующим образом:

Разработка этого контракта строго соответствует стандарту программного обеспечения:

  1. Высокий охват местными модульными тестами;
  2. Функциональное и нагрузочное тестирование в тестовой сети Kovan Ethereum;
  3. Осведомление в сети Эфириума;
  4. Выпущен для кампании.

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

Оригинальная статья




88 Views0 Replies0 Subscriptions
Loading