Команда block.one работает почти круглосуточно, чтобы закончить EOS Dawn 3.0 в рамках подготовки к нескольким месяцам тестирования перед июньским релизом EOSIO 1.0. Разработчики отмечают значительные улучшения по сравнению с предыдущими релизами. Одно из этих усовершенствований касается того, как определяются контракты.
Ниже я представил минимально жизнеспособный контракт токена. Он позволяет создателю выпускать токены, а пользователям – передавать их друг другу. Следует отметить, что данный минимально жизнеспособный контракт токена не соответствует предлагаемому нами стандарту токена. Это просто пример.
#include <eosiolib/eosio.hpp>
class simpletoken : public eosio::contract {
public:
simpletoken( account_name self )
:contract(self),_accounts(self, self){}
/** User's call this method to transfer tokens */
void transfer( account_name from, account_name to, uint64_t quantity ) {
require_auth( from );
const auto& fromacnt = _accounts.get( from );
eosio_assert( fromacnt.balance >= quantity, "overdrawn balance" );
_accounts.modify( fromacnt, from, [&]( auto& a ){
a.balance -= quantity;
} );
add_balance( from, to, quantity );
}
/** Contract owner can issue new tokens */
void issue( account_name to, uint64_t quantity ) {
require_auth( _self );
add_balance( _self, to, quantity );
}
private:
struct account {
account_name owner;
uint64_t balance;
uint64_t primary_key()const { return owner; }
};
/** account database maps owner to their balance */
eosio::multi_index<N(accounts), account> _accounts;
void add_balance( account_name payer, account_name to, uint64_t q ) {
auto toitr = _accounts.find( to );
if( toitr == _accounts.end() ) {
_accounts.emplace( payer, [&]( auto& a ) {
a.owner = to;
a.balance = q;
});
} else {
_accounts.modify( toitr, 0, [&]( auto& a ) {
a.balance += q;
eosio_assert( a.balance >= q, "overflow detected" );
});
}
}
};
EOSIO_ABI( simpletoken, (transfer)(issue) )
Важные нововведения
- Теперь действия являются простыми методами класса
- Нет необходимости использовать макросы сериализации
- Значительно более короткий код
- Макрос EOSIO_ABI отображает ваши действия
- Доступ к базе данных теперь boost:: multi_index_container
Переведено @blockchained
Оригинал поста: ЗДЕСЬ
Телеграм чат: https://t.me/EOS_RU
Вы можете торговать токенами EOS на RuDEX
что бы я ещё понимал что всё это значит... (
Но наверное хорошо что разработка шевелится.
На днях стал разбираться с EOS и кода дошел до примеров смарт контрактов очень загрустил. Язык похож на С, а это делет его плохо читаемым по сравнению с Python и другими современными языками. Вот эти вот [&]( auto& a ). Даже solidity гораздо легче читать. Бутерин говорл о проблемах аудита больших проектов, что инвесторы должны тратить много средств, что бы проверить не содержат ли смарт контракты уязвимостей и как вариант решения этой проблемы оны работают над языком Viper, который очень похож на Python. В этом плане мне нравится идея в SMT - стандартные смарт контракты для токенов, они встроены в систему и их нельзя сломать сделав что-либо неправильно.
Надеюсь что этот язык в EOS лишь POC (proof of concept) и они сделают что-то более удобное для разработки.
Этот язык - C++. Для квалифицированного C++ разработчика это не представляет никаких проблем. Конструкция [&]( auto& a ) - отличнейшее нововведение в новый стандарт языка, говорящее о том, что все переменные из области видимости в месте вызова будут переданы по ссылке объекту-функции, которая принимает в качестве параметра ссылку на тип, автоматически выводимый компилятором в месте вызова этой функции :-)
И да, C++ будет основным языком для разработки смарт-контрактов в EOS, Ден это лично писал в телеграм-чате разработчиков, отвечая на вопросы.
В дальнейшем будут и другие языки, но только те, которые будут поддерживать WebAssembly. Правда, немногие будут способны потягаться с C++ по производительности и по объему исполняемого кода, что чрезвычайно критично для смарт-контрактов.
Я хочу поспорить :) На мой взгляд в программировании децентрализованых приложений, главное не столько объем исполняемого кода, сколько читаемость которая позволяет легче находить ошибки, что бы не повторять судьбу The DAO. Любой язык можно "скомпилировать" в аналог байт кода, который будет компактен и оптимизирован для исполнения. Поэтому мне кажется что выбор C++ большая ошибка, которая негативно повлияет в конкуренции с ETH.
Что такое читаемость кода? Понятие относительное. Для C++ разработчика описанный выше контракт вполне хорошо читаем. В то же время контракт на Solidity для того же разработчика - китайская грамота. Кстати, именно контракт на Solidity и привел к печальной судьбе The DAO, и его читаемость никак ему не помогла :)
Если же говорить о конкуренции, то ETH уже теряет расположение разработчиков, постепенно отказывающихся от него в пользу EOS. И большинство претензий именно к скорости работы ETH. Кроме того, наличие большого количества готовых C++ программистов, которым не нужно изучать еще один язык, тоже играет свою роль.
Претензии к Solidity имеются и в плане того, что под него нет развитой поддержки - IDE, библиотек и так далее. По сети гуляет немало жалоб о том, что на Solidity постоянно приходится изобретать велосипеды, потому что нет готовых решений в виде библиотек. И это тоже ведет к ошибкам в контрактах.