Перейти к публикации
GlavFish

Ethereum [ETH] - платформа для смарт-контрактов

Рекомендованные сообщения

12.06.2019 в 14:08, cp287 сказал:

Виталик предлагает (а как мы знаем на опыте Uniswap, значит скорее всего готов поддержать и рублём) разработку миксера на Ethereum, где можно было бы легко и просто отправить необходимую сумму на необходимый адрес, скрывая адрес отправителя (миксер с простым интерфейсом, как Uniswap): https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/rJj9hEJTN

 

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

Оказалось, что что-то похожее уже есть: https://github.com/argentlabs/hopperhttps://hoppereth.org/

 

Цитата

users can deposit notes of 1 ETH into a mixer smart contract and withdraw them later to a different account by only providing a Zero-Knowledge proof (zkSNARK) that they previously deposited a note into the mixer, without revealing from which account that note was sent

"Пользователь может задепозитить 1 ETH в умный контракт, и вывести их на другую учётную запись предоставляя только доказательство нулевого знания своего депозита (zk-SNARK) без раскрытия с какой учётной записи был сделан депозит.

Поделиться сообщением


Ссылка на сообщение

Статистика:

 

20 тысяч смарт-контрактов создаётся ежедневно

Менее 1% контрактов имеют открытый исходный код

25% от всех смарт-контрактов имеют какую-то ошибку

 

и практические советы для разработчиков Solidity

https://medium.com/quiknode/practical-advice-for-solidity-developers-f2c33b88c0e6

 

Поделиться сообщением


Ссылка на сообщение
19.06.2019 в 08:55, cp287 сказал:

Оказалось, что что-то похожее уже есть: https://github.com/argentlabs/hopperhttps://hoppereth.org/

 

 

Круто. Жаль что пока только iOS и только 1 ETH

Вообще как я понимаю в ETH2 будет решена эта проблема приватности. Там слишком сильный упор делают на Snarks в разработке

Изменено пользователем alexbots

Поделиться сообщением


Ссылка на сообщение

А вот и атомарные свапы ETH (и DAI)и BTC с нормальным интерфейсом подъехали: https://liquality.io/swap/

Т.е. теперь можно без посредников поменять свои BTC на чьи-то ETH и наоборот.

Поделиться сообщением


Ссылка на сообщение

Виталик поднял проблему непонимания как валидаторам в различных средах с различными спецификациями принимать оплату, и предложил сделать её унифицированной (en): https://ethresear.ch/t/one-fee-market-ee-to-rule-them-all/5608

Поделиться сообщением


Ссылка на сообщение

Rocket Pool. Команда готовится к запуску Ethereum 2.0 и создаёт пулы которые помогают участвовать в стекинге тем у кого меньше 32 ETH 🙂

 

https://www.rocketpool.net

Whitepaper https://www.rocketpool.net/files/RocketPoolWhitePaper.pdf

Поделиться сообщением


Ссылка на сообщение
11 часов назад, alexbots сказал:

Rocket Pool. Команда готовится к запуску Ethereum 2.0 и создаёт пулы которые помогают участвовать в стекинге тем у кого меньше 32 ETH 🙂

 

https://www.rocketpool.net

Whitepaper https://www.rocketpool.net/files/RocketPoolWhitePaper.pdf

Что-то мне подсказывает, что желающих будет не так много, как им бы хотелось (по опыту других проектов).

Поделиться сообщением


Ссылка на сообщение

Cloudflare разработала шлюз к Ethereum, который даёт возможность доступа к сети без установки какого-либо программного обеспечения. С помощью API Cloudflare разработчики могут добавлять элементы из сети Ethereum на свои сайты, позволяя снизить нагрузку на API Infura.

Поделиться сообщением


Ссылка на сообщение

Выдумщики продолжают придумывать всё новые и новые модели контрактов на Ethereum. Так утилита HomeWork позволяет создать контракт с постоянным адресом, но без постоянного кода. Код может быть предоставлен и заменён (посредством повторного развёртывания) через новую транзакцию путем ссылки в этой транзакции на другие контракты.

Таким образом в одном и том же контракте могут быть постоянно меняющийся код по вашему выбору. 

Кроме того HomeWork позволяет выпускать токен ERC721 для своего домашнего адреса. Владелец этих незаменяемых токенов может выкупить их, чтобы получить контроль над изменением кода контракта по данному адресу.

 

Модель явно не идеальна, но новые применения всегда радуют и могут натолкнуть на какое-то дальнейшее интересное развитие данных идей.

 

Адрес HomeWork в сетях Mainnet, Ropsten, Rinkeby, Kovan и Goerli: 0x0000000000001b84b1cb32787B0D64758d019317

Поделиться сообщением


Ссылка на сообщение
12.06.2019 в 14:08, cp287 сказал:

Виталик предлагает (а как мы знаем на опыте Uniswap, значит скорее всего готов поддержать и рублём) разработку миксера на Ethereum, где можно было бы легко и просто отправить необходимую сумму на необходимый адрес, скрывая адрес отправителя (миксер с простым интерфейсом, как Uniswap): https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/rJj9hEJTN

 

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

Инженер-программист Кендрик Тан встретился с Виталиком по поводу его статьи о миксере, и 3 июля представил миру реализацию этой идеи: https://heiswap.exchange/

Быстро работают ребята) Можно теперь спокойно мыть эфирку.

Поделиться сообщением


Ссылка на сообщение
33 минуты назад, cp287 сказал:

Инженер-программист Кендрик Тан встретился с Виталиком по поводу его статьи о миксере, и 3 июля представил миру реализацию этой идеи: https://heiswap.exchange/

Быстро работают ребята) Можно теперь спокойно мыть эфирку.

А для каких благородных целей нужны миксеры?

Поделиться сообщением


Ссылка на сообщение
2 часа назад, jake_cody сказал:

А для каких благородных целей нужны миксеры?

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

Поделиться сообщением


Ссылка на сообщение

Произошёл выпуск клиента Go Ethereum (Geth) v1.9.0, который несёт в себе очень много нововведений и изменений. Для того, чтобы более близко ознакомиться с ними я советую вам прочитать оригинальный пост, а я постараюсь кратко пробежать по тому, что нас ожидает.

  • Разработчики тщательно поработали над производительностью клиента. После проделанной оптимизации сразу по нескольким фронтам в ходе тестов на одинаковых машинах время быстрой синхронизации уменьшилось с 11 часов 20 минут до 4 часов 8 минут,  время полной синхронизации снизилось незначительно с 6 дней 15 часов 30 минут до 6 дней 8 часов 7 минут (хотя где-то на треть уменьшилось использование памяти, что в свою очередь увеличило нагрузку на считывание/запись с диска), а время синхронизация архивной ноды снизилось с 62 дней 4 часов до 13 дней 19 часов;
  • появилась возможность разделить базу данных на две части: в первой части - последние блоки, все состояния и структуры ускорений хранятся в быстром хранилище (LevelDB), предназначенным для работы на SSD, а блоки, которые не входят в последние 3 эпохи (30.000*3 блоков), будут храниться в пользовательской базе данных, морозилке (freezer);
  • вместо JSON-RPC запросов теперь можно использовать более гибкие GraphQL-запросы;
  • появилась встроенная поддержка аппаратных кошельков Ledger Nano X, Trezod Model T, поддержку как обновлённых, так и использующих старую версию Trezor One, кошелёк keycard от Status;
  • выделение подписчика (signer) в отдельный проект под названием Clef, который, как надеются создатели, будет использоваться для различных пользовательских интерфейсов;
  • выпуск ультра-лёгкого клиента, который сможет использовать собственные адреса доверенных серверов с чекпоинтами, при этом синхронизация на тестах была в 10 раз быстрее, чем использование лёгкого клиента;
  • была добавлена большая поддержка мониторинга различных систем и событий с возможной визуализацией через внешние программы/сервисы;
  • встроенный Puppeth и Blockscout. Puppeth - инструмент создания новой сети Ethereum, созданный для развёртывания Rinkeby и используемый для запуска других частных клонов Ethereum, а Blockscout - первый опенсорс блокэксплорер, созданный командой POA Network;
  • новая версия протокола обнаружения, позволяющая лучше определять нодам другие узлы, находящиеся в этой же сети;
  • новый список загрузочных узлов, которые обслуживают теперь и лёгкие клиенты;

 

Кроме этого было сделано много чуть менее значимых, но важных изменений. Всего данное обновление содержит около 370 изменений. :party-popper:

Поделиться сообщением


Ссылка на сообщение

Plasma Group (как нетрудно понять из названия, это группа людей, работающих над Plasma-решениями) представила общественности Optimistic Virtual Machine (OVM, по аналогии с EVM), оптимистическую виртуальную машину. Главной задачей данной машины является обслуживание и поддержка любых (!) протоколов второго уровня (Layer2-протоколов). Подход к данному решению исходит из изучения CBC Casper, и описывает второй уровень как естественное расширение консенсуса первого уровня, а не как какое-то отдельное решение.

Поделиться сообщением


Ссылка на сообщение

Прошла AMA для исследователей Ethereum, и Эрик Коннер из Гносис постарался собрать самое интересно у себя в твитт-шторме, а я переведу это на русский.

 

1. Виталик Бутерин о нерешённых проблемах: "Я действительно искренне думаю, что не решенных проблем для исследования не осталось на данный момент".

2. Джастин Дрейк о том, когда Beacon-цепь начнёт завершение цепи Eth 1.x: "В лучшем случае в начале 2021 года".

3. Виталик Бутерин о сложности Eth 2.0: "Стало значительно проще за последний год. Много вещей, которые проще в Eth 2.0 чем в eth 1.x. Но некоторые требуют много времени для решения, и я тщательно забочусь для минимизирования этого времени".

4. Карл Бикхуизен о разнообразии клиентов: "Я ожидаю консолидации - куча клиентов может не выжить в 2020 году".

5. Карл Бикхуизен о проблеме отключения узлов валидаторов и потерей данных в связи с этим: "Если ваша валидаторская нода переходит в автономный режим в течение 18 дней, а Beacon-цепь не финализирована, то ваш баланс будет "оштрафован вплоть до 60.8% в течение 18 дней".

6. Карл Бикхуизен о штрафах: "Если валидатор ведёт себя доказуемо злонамеренно, то они будут наказаны их балансы будут сокращены. Если предполагать, что программное обеспечение написано хорошо, то это не должно случиться с обычными держателями валидаторских нод. Минимальное наказание составляет 1 Eth и увеличивается линейно".

7. Карл Бикхуизен об атаках: "PoS прекрасен тем, что атаки могут быть отражены изящны. Коммьюнити может сделать хард-форк, забрав у атакующих голоса. Таким образом атакующие просто сожгут кучу денег просто остановив ненадолго сеть".

8. Виталик Бутерин о миграции из Eth1 в Eth2: "В данный момент подход состоит в том, чтобы вложить Eth1 в Eth2. На практике это будет означать, что мы должны сделать хард форк в Eth1 чтобы ребалансировать некоторые цены газовые цены".

9. Виталик Бутерин о неравенстве богатства: "Я все ещё думаю, что PoW не лучше PoS с точки зрения неравенства, потому что хоть PoW и даёт монеты в "новые руки", вам нужно так много денег, чтобы стать PoW-майнером, что майнер становится большим богатый-становится-богаче механником".

10. Карл Бикхуизен об ожидании фазы 1/2: "Фаза 2 слишком далеко, сложно сказать. По фазе 1 - я надеюсь, что она будет осуществлена в 3-4 квартале этого года".

11. Джастин Дрейк о запланированном простое/паузе: "Ближе всего кнопка "пауза" находится к первому выходу (который может занять как всего полчаса, так и несколько дней/недель в связи с механизмом очереди)".

12. Виталик о текущем механизме переноса контрактов: "В данный момент подход состоит в том, чтобы вложить Eth1 в Eth2 как среда выполнения через клиент без сохранения состояния. В данном случае контракты будут продолжать работать как ожидалось изначально".

13. Джастин Дрейк о производительности Eth2 по сравнению с Eth1: "2.0 не будет содержать узкого места в виде отклика записи/чтения диска для участников консенсуса сильно склоняясь к клиентам без состояния. Финальность в значительной степени убирает проблемы связанные с задержкой синхронизации, и  требование к участникам консенсуса хранить старые блоки".

14. Виталик Бутерин о сокращении PoW-награды: "Когда PoW-цепь начнёт перемещаться на PoS-цепь для безопасности (это может случиться в первой или второй фазе), тогда станет безопасно снизить награду PoW-цепи в четыре раза. Дальнейшие сокращения произойдут только когда PoW полностью прекратит свою работу".

15. Карл Бикхуизен, мысли о том, когда биржи залистят Eth2: "Переводы будут работать в фазе 1, когда видимо биржи и залистят Eth 2.0. Наличие бирж поможет сохранить ценовой паритет между ETH 1.0 и ETH 2.0".

16. Джастин Дрейк о мосте: "Мост в одну сторону из Eth1 в Eth2 будет поставлен вместе с beacon-цепью. Я бы даже предположил, что этот мост будет сразу в две стороны в конечном итоге, но это вряд ли произойдёт в 2020 году. Гораздо лучше чем мост в две стороны было бы иметь интеграцию Eth1 в Eth2.

17. Виталик Бутерин, DeFi против стейкинга: "Ставка Compound по eth на данный момент около 0.02% насколько я знаю, и с этим очень легко конкурировать.  Фразы типа "вы выберете 3% стейкинга или 6% лендинга в DAI на Compound" очень часто вводят в заблуждение, т.к. иметь 6% в USD и 3% в Eth - это совсем разные вещи".

18.  Виталик Бутерин о том как запустить 10 валидаторов: "Ноутбука должно быть достаточно. Мы будем лучше знать через несколько месяцев, когда определим размер блока и лимиты газа для блоков в шардинге".

19. О наградах нод в Beacon-цепи: "Ноды в Beacon-цепи, которые не являются валидаторами, не будут получать вознаграждение, так как протокол не может определить кто действительно является нодой в beacon-цепи, а кто просто маскируется. Но не валидирующие узлы могут зарабатывать деньги в Eth2 с помощью инициативных (т.е. с оплатой) протоколов лёгких клиентов".

20. Виталик Бутерин об ожидаемой пропускной способности: "Где-то между 5000 и 500.000 транзакций в секунду в зависимости от того какую среду выполнения и транзакции какого типа вы используете".

21. Денни Райан о парачейне Eth2 в Polkadot: "Я не думаю, что Ethereum Foundation будет заниматься этим. W3F и Parity отвечают за это, и я верю, что это один из главных приоритетов. Клиент Shasper (Parity) написан на субстрате для облегчения этой задачи".

22. Денни Райан о росте размера цепи: "Ожидается, что шардинговый Eth2.0 будет обрабатывать ~10MB/сек доступных данных. Эти данные будут учтены в консенсусе шардов и гарантированно будут доступны по крайней мере 2 недели. Это не обязательно будет размер состояния. Актуальный подход к состоянию и исполнению состояния заключается в том, чтобы привести его к подходу без сохранения состояния, в котором блоки должны содержать Меркль-свидетелей соответствующего состояния.

 

Поделиться сообщением


Ссылка на сообщение

Проект Hookpad пытается решить одну из актуальных проблем работы в Ethereum на данный момент. С ростом инфраструктуры не сильно развивались возможности к доступу данных из блокчейна. Infura по сути стала центральной точкой отказа для многих крупных проектов. Hookpad стремится решить эту проблему путем прямого подключения к любой цепочке на основе EVM и хранения данных в легко потребляемом формате и полностью управляемым способом. Чем-то похоже на thegraph, но подход с другой стороны. И пока слишком мало подробностей. За проектом стоит команда, создавшая Cryptowars. Бета-версия открыта прямо сейчас.

Поделиться сообщением


Ссылка на сообщение

Как и обещал, пишу про уязвимости и ошибки в истории существования смарт-контрактов. Этот блок я сделаю в нескольких подчастях. Так как интересной и полезной информации довольно много.

Полетели🚀

 

Часть 1. Уязвимости и ошибки в истории смарт-контрактов
Вот какие ошибки считаются самыми популярными и значимыми в истории смарт-контрактов:

1) The DAO 1.0
2) FirePonzi
3) Казино с публичным RNG-сидом
4) Зависли 1100 ETH из-за нехватки газа
5) Игра The King of the Ether
6) 5800 ETH вывели из токенов ERC-20
7) Rubixi

 

Самыми крупными хищениями стали 30 миллионов долларов из Parity и 53 миллиона долларов из DAO. 

 

Я постараюсь кратко, но в то же время подробно описать эти уязвимости.

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

 

Начну по порядку.

1) Про уязвимость в DAO.

Атаку назвали
- "Повторный вход, Reentrancy"
- Race-To-Empty
- Recursive call vulnerability, (рекурсивный вызов)
- Call to the unknown (призыв к неизвестному).

Любое действие в блокчейне Ethereum выполняется с помощью транзакций: отправка ether с одного аккаунта на другой, создание контракта, обращение к функции контракта. Причем инициировать транзакции могут только внешние аккаунты, а контракты могут создавать транзакции только под действием полученных ими транзакций. За каждую транзакцию взимается комиссия, для этого введена специальная единица — gas. Комиссия рассчитывается как произведение цены gas и количества gas.

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

Все дело в функции "withdraw".

Функция «withdraw» имеет модификатор «onlyOwner», т.е. может быть вызвана только владельцем смартконтракта. Единственное, что она делает – переводит весь баланс смартконтракта на адрес владельца смартконтракта.

Почему назвали повторный вход? 

Контракт жертвы выполняет функцию для отправки ETH во вредоносный контракт до обновления баланса вредоносного контракта.

В мошенническом контракте есть функция возврата fallback(), которая принимает средства, а затем возвращает их обратно в функцию withdraw(). Эта функция необходима, если нужно, чтобы контракт получал эфир.

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

Рекурсивный вызов удается выполнить только один раз; нужные нам балансы в итоге ставятся в 0, и на этом все заканчивается. Однако атакующий смог повторить эту операцию как минимум раз 50. 

Если адрес является смарт-контрактом, платеж вызовет резервную функцию fallback () с тем, что осталось от транзакционного газа.

Таким образом, пользователь получит в два раза больше своего баланса из контракта.

Безопаснее было перевести токены при помощи функции transfer(), которое должно испускаться смартконтрактом при каждой операции перемещения токенов между держателями токенов. Но если все же необходимо использовать вызов аккаунта, то нужно было сначала обновить баланс аккаунта, а затем уже совершать вызов.

Самое интересное, что баг в коде был не один. Именно совокупность этих багов и помогла хакеру украсть так много. Ошибка стала результатом плохого программирования, и вероятно типографской ошибки в коде.

 

photo_2019-07-25_01-56-21.thumb.jpg.203ae0ea32263d120345aae764adacea.jpg

 

Часть 2. Критическая уязвимость в multisig кошельке Parity
В 2017 году в кошельке Parity была найдена уязвимость, через использование которой было похищено порядка $30 миллионов. В результате взлома пострадали все пользователи, имевшие дело с кошельками с мультиподписью.

 

Интересно, что почти сразу после обнаружения  взлома, группа энтузиастов, называющих себя The White Hat Group, воспользовалась тем же эксплоитом, чтобы спасти деньги пользователей, переведя их на неподверженный багу кошелек. Суммарно насчитывалось 596 уязвимых кошельков, и основной удар злоумышленников пришелся на три из них. Среди них был кошелек блокчейн-стартапа Aeternity.

Проблема возникла в результате ошибки в отдельном контракте с мультиподписью известном как wallet.sol. 

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

 

Функция initWallet() в коде, позволяющая определить владельца кошелька, оказалась публичной, и её мог вызвать любой человек. После переопределения владельца оставалось только перевести деньги.

 

Взломщик отправил в каждый пострадавший контракт:

- одну транзакцию содержащую вызов функции initWallet, которая обеспечивала ему исключительное право на владение кошельком с мультиподписью

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

 

Из-за устройства MultiSig-кошельков Parity, кошелек перенаправляет все вызовы на другой контракт — контракт библиотеки. В библиотеке и «реализована вся функциональность» контракта, что позволяет не писать отдельный код для каждого кошелька.

Метод initWallet, отвечающий за инициализацию (подготовку к использованию) кошелька, был общедоступен.

«Предполагается, что метод будет вызываться только один раз во время создания контракта кошелька. При заведении нового кошелька, транзакция отправляется в Ethereum, где написано "Заведи новый кошелек, который ссылается на эту библиотеку", и автоматически в момент создания контракта кошелька срабатывает функция initWallet в библиотеке, которая и назначает владельца этого кошелька»

 

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

Parity признали, что взлом стал возможен именно из-за этой ошибки в коде:

«Баг находился в двух крайне чувствительных функциях, разработанных для установки кошельков с мультиподписями в ПО кошелька Parity. Функции должны были быть защищены так, чтобы они могли использоваться только в одном случае — при создании контракта. Однако они были не полностью защищены, что позволило хакеру произвольно переустановить параметры владельца и использования».

 

Дальше еще интереснее...

 

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

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

Было много предложений для разморозки средств.  Вот ссылочка (https://cryptowiki.ru/news/novoe-predlojenie-parity-o-vozvrate-zamorojennyh-eth.html), кому интересно, что это были за предложения. А пока, средства все еще заморожены...Все работают над проблемой масштабируемости сети Ethereum.

 

Часть 3. Ошибка в смарт-контракте лотереи "Король Эфирного Трона"

Игра "Король Эфирного Трона" — наиболее известный случай ошибки «unchecked-send», "silent failing sends".

Игра «Король Эфирного Трона» (KotET) — это игра, в которой участники соревновались друг с другом за титул «Король эфира».

Суть игры вот в чем:

1) Допустим, что текущая цена за трон (но не за тот самый😄) составляет 10 эфиров.
2) Мы хотим быть королем, поэтому отправлям 10 эфиров.
3) Контракт отправляет 10 ETH предыдущему королю качестве компенсации.
4) Контракт делает нас новым Королем Эфирного Трона.
5) В этом случае новая цена за трон увеличивается на 50%, до 15 ETH.
6) Если приходит тот, кто готов заплатить 15 эфиров, он свергает вас, но вы получаете свою выплату в 15 эфиров.

Проще говоря, это была пирамида.

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

Когда платеж не обработался, уплаченный эфир был возвращен в контракт KotET. Но организация не знала, что платеж не прошел и продолжал обработку.

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

Проблема здесь в том, что метод send может выполниться с ошибкой. Если он не сработает, то победитель не получит деньги, однако переменная prizePaidOut будет установлена в True.

Существуют два разных случая, когда функция отвечающая за получение приза может выйти из строя:

1) Адрес winner — это контракт, а не учетная запись пользователя. Код этого контракта генерирует исключение (например, если он использует слишком мало «газа»). Если это так, то, возможно, в этом случае это «ошибка победителя». 

2) Виртуальная машина Ethereum имеет ограниченный ресурс, называемый «callstack» (глубина стека вызовов), и этот ресурс может быть использован другим кодом контракта, который был выполнен ранее в транзакции. Если callstack уже израсходован к моменту выполнения команды send , выполнение команды потерпит неудачу, независимо от того, как определен winner. Приз победителя будет уничтожен не по его вине! 

Эта ошибка не была замечена, пока сумму 200 эфиров не смог получить законный победитель лотереи.  К счастью, разработчик контракта смог использовать несвязанную функцию в контракте в качестве «ручного переопределения» для выпуска застрявших средств. 

Эта ошибка имелась в популярном лотерейном контракте EtherPot. Более ранняя версия BTCRelay также показала эту ошибку.

 

 

источник: tg - CryptoBotan

 

Поделиться сообщением


Ссылка на сообщение

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

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

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.


×
×
  • Создать...