Изучаем Solidity

[Mitch]

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

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

Также в этой идее мне понравилось то, что тут короткий стек технологий и отсутствие тяжелого наследия старых версий. Например если изучать веб програмирование, то там в стек технологий надо сразу JS+SQL+язык.

А тут достаточно просто одного solidity плюс понимание работы блокчейна и криптографии.
Минус в том что с документацией, книгами курсами дела пока обстаят не очень, особенно на русском.

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

1. Язык Solidity: Неllo World (Урок 1)
очень понравилось изложение материала, поэтому поставлю пока первым в списке.
2. [Russian] Руководство по Solidity
Это перевод официальной документации.
Много инфы, но встречаются не переведенные с английского куски
3. Официальная документация на английском

Вот еще пачка статей на русском:
https://habrahabr.ru/post/327236/
https://habrahabr.ru/post/312008/
https://habrahabr.ru/company/neobit/blog/324456/
https://habrahabr.ru/company/neobit/blog/324456/
https://habrahabr.ru/post/335710/

[1714801255]

1714801255

[1714801255]

1714801255

[1714801255]

1714801255

[1714801255]

1714801255

[Mitch]

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

На solidity я хочу написать контракт честной лотереи, на результат розыгрыша которой владелец контракта не сможет повлиять.
Сама идея такая:

Все кто хочет участвовать в лотерее отсылают на адресс смарт контракта эфириум, кто сколько хочет.
Каждый 1 wei (минимальный обьем эфира) получает "билет в лотерею".
В момент розыгрыша, ну например каждый 100й блок главной ветки смарт контракт случайным образом определяет победителя и отсылает ему все деньги за вычитом 10% которые он скидывает мне.

Идея вроде простая
Теперь читать документацию и начинать писать и тестировать.

[Coin-1]

Хорошие туториалы, написано простым языком, всё понятно. Но Solidity - это привязка к конкретной монете Ethereum.

[Mitch]

Хорошие туториалы, написано простым языком, всё понятно. Но Solidity - это привязка к конкретной монете Ethereum.

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

[Mitch]

Гуглил как же выяснять кто нам слал деньга на контракт и как работать с временем, нагуглил еще один сайт с уроками по смарт контрактам
http://inaword.ru/smart-kontrakty/

Итак, можно используя "fallback function" (которая вызывается в момент прихода эфира на контракт)
записывать в переменные состояния новую запись.
Данные логично хранить в структуре вроде
mapping (address => uint256) client_tickets;
Надо теперь глубже с массивами разобраться.
Архитектурно получается вот так
адрес1 -> сумма1
адрес2 -> сумма2
.....
адресN -> сумма_N
значит в момент розыгрыша надо:
- сложить все полученные суммы от сумма1 до сумма_N
- сгенерить случайное число X, такое что 0 < X < N
- X соответственно покажет адрес победителя которому надо отдать приз (складываем суммы начиная с первой полученной и до тех пор пока сумма не станет больше X)

Для определения а не пора ли сделать розыгрыш можно использовать now

интересные вопросы над которыми я думал:
1. Откуда now берет время?
С виртуальной машины майнера который взялся исполнять контракт?
Может ли быть на этой VM неправильное время, может не стоит к времени привязываться а ориентироваться по номерам блоков..

2. Могут ли возникнуть коллизия когда одновременно 2 человека послали деньги на контракт (ведь очередность прихода денег у нас фактически определяет "номер билета в лотерее") ?
Исходя из моего понимания логики работы блокчейна, от этого мы застрахованы.
Даже если в физическом мире они отправили деньги одновременно, транзакции в блоке все равно будут записаны последовательно.

[torwig]

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

[Mitch]

Еще не добрался до этого вопроса.
Погуглил сейчас - пишут что встроенной функции random() нету в solidity
и что это вообще может быть проблемой, тк VM одна и таже и непонятно откуда взять случайность.

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

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

Смотрю на доступные переменные, думаю может использовать block.blockhash (function(uint) returns (bytes32)): hash of the given block - only works for 256 most recent blocks
Например в 12:00 "продажу билетов завершаем"
Ждем 10 минут, и используем как базу для случайного числа хеш блока найденого после 12:05

[TechPriest]

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

Без обид, но вы не туда пришли в таком случае. Все, что вы выучите, скорее всего пойдет вам на пользу в плане личностного развития, но не карьерного.
Вы хотите работать в блокчейне, но вопрос: Почему вы не работаете программистом просто так? Например фуллстак разработчиком? Или не пишете контроллеры на плюсах?

Проблема того же Солидити, что он высокоуровневый. Он довольно сырой и забагован, притом, мало кто сейчас понимает как Солидити взаимодействует с системой на низком уровне (большинство "взломов" смартконтрактов, их некорректной работы связанны именно с этим) Человек видит облочку, пишет контракт. Если смотреть по программе - все корректно и хорошо. Контракт запускается в сеть, и хоп, что-то вылазит. Или не вылазит, а кто-то пользуется тем, что на низком уровне все работает не совсем так.

Например, у меня в закладках была статья с примерами так называемого "говнокодинга" на Солидити. Ужас был в том, что по коду все выглядело красиво, но работало не так. Из того что помню, был код, элементарный, который через Н дней отправлял платеж на некий адрес. Но так как первая транзакция не подтвердилась (не успела или сеть была загружена) контракт наспамил еще пару транзакций пока баланс не опустел.

Что бы писать на Солидити, нужно понимать низкие уровни. Поэтому я бы вам советовал написать некий смарт контракт с помощью сети Биткоина (его язык позволяет писать элементарные контракты). Это намного поможет вашему пониманию.

[Mitch]

20 лет назад я изучал турбо паскаль годик в школе
потом еще чуток сам изучал C
потом когда работал админом немного писал на баше
а когда занимался вебмастерской деятельностью иногда что то правил по мелочи в php особо не углубляясь.

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

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

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

Изучить как работает блокчейн на низком уровне я конечно планирую, это интересно.

[m2017]

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

На solidity я хочу написать контракт честной лотереи, на результат розыгрыша которой владелец контракта не сможет повлиять.
Сама идея такая:

Все кто хочет участвовать в лотерее отсылают на адресс смарт контракта эфириум, кто сколько хочет.
Каждый 1 wei (минимальный обьем эфира) получает "билет в лотерею".
В момент розыгрыша, ну например каждый 100й блок главной ветки смарт контракт случайным образом определяет победителя и отсылает ему все деньги за вычитом 10% которые он скидывает мне.

Идея вроде простая
Теперь читать документацию и начинать писать и тестировать.

а ты харошшШ... решил запилить "налог для дураков" на блокчэйне...

[atlantik]

Привет, встречал небольшой курс на сайте http://inaword.ru по солибиту, посмотри может что подчерпнешь

[Mitch]

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

[Ranyar]

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

[Mitch]

Ну я вообще то его там и делал.
Модератор зачем то перенес сюда.

[TechPriest]

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

Вот здесь и кроется проблема. Ведь все наоборот.
Для работы в сфере блокчейна нужно и вэб хорошо знать, и криптографию понимать и еще много чего. Среднее требование это что-то в стиле: написать сайт который бы принимал биткоины. Тоесть нужно и сайт сверстать, и платежку подключить.
Во вторых, сейчас предложение по работникам превышает спрос в 2.5 раза. Или около того. То, что вы сможете сделать сможет сделать любой другой конкурент, поэтому выхлоп будет небольшой. А то, за что в теории хорошо заплатят вы не сможете сделать как минимум года два, так как нельзя с нуля сесть и написать что-то серъезное.

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

[Mitch]

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

[Mitch]

Возник вопрос, mapping итерируемый или нет?
Если нет, то получается в лотерее для хранения поступлений нужно использовать двойной mapping.
Первый ключ порядковый номер поступления денег и каждому номеру соответствует пара адресс и сумма.
mapping (ticket_number => mapping (address => uint256)) client_tickets;

Нумеровать начиная с 0, и еще завести переменную в которой хранить
номер последнего билета добавленного в базу.
last_ticket_number uint256;

Выглядит как изобретение велосипеда, который давно должен существовать.
Может mapping итерируемый все же, а мне это пока в доках не встретилось.
Пока решил последовательно пройти все уроки с inaword.ru
Читаю, вникаю, все примеры пробую на работоспособность в remix.

Разбирать рабочие примеры получается эффективнее чем последовательно читать доки и по ней пытаться сделать сразу.

[Mitch]

В комментах на  inaword нашел ответ на возникший вопрос:
А как же подключать библиотеки в remix?

Надо добавить в начале кода импорт библиотеки, причем можно напрямую с github!
Пример:
import "github.com/OpenZeppelin/zeppelin-solidity/contracts/token/MintableToken.sol";

Такая запись так же подгружает всё на что MintableToken.sol ссылается внутри.

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

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

[Mitch]

Думал над архитектурой данных своей тестовой лотереи.
Пришел к мысли что надо сделать фиксированную цену "лотерейного билета".
Вопервых, цена билета должна быть значительно выше средней комиссии за транзакцию эфира, ну хотя
бы в 20 раз, чтоб не получилось так что получилась сплошная раздача денег майнерам на микротранзакциях.
Сейчас комиссия менее 0.2$
Если бы не комиссия то я бы делал билеты примерно по 1$
А с учетом комиссии значит надо делать минималку около 5-10$.
Курс эфира сейчас около 400-800$, значит пусть будет цена 1го билета в лотерею = 0.01eth

При поступлении эфира на кошелек контракта вызываем fallback функцию
  function() external payable {
тут надо:
1. выяснить на какое количество билетов хватает входящего платежа, и записать за номером кошелька участника номера лотерейных билетов которые он приобрел.
2. сохранить эти данные в контракте до момента розыгрыша.
стуруктура данных напрашивается
mapping (uint => address  ) client_tickets;
индексное поле целочисленное без знака uint это номер билета лотереи, а address это кошелек участника которому надо выдать приз если билет выиграет.
Номера билетов присваиваем последовательно, в отдельной переменной контракта сохраняем последний выданный номер билета.
uint ticket_count;
В конструктор контракта вписываем для определенности
ticket_count = 0;

Если участник прислал например 0.05 эфира то выдаем ему 5 билетов, записав подряд 5 записей в наш mapping с данными.
Мне конечно не очень нравится, что я вроде делаю неоптимальные записи, экономнее то записать
кошелек_N:0.05
чем
1:кошелек_N
2:кошелек_N
3:кошелек_N
4:кошелек_N
5:кошелек_N

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

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

Что делать с остатком если участник прислал денег на дробное количество билетов?
Вариантов тут 3
1. вернуть сдачу (если она больше чем комиссия)
2. прибавить к призовому фонду
3. забрать организатору
Выберу 2й пункт.

[Mitch]

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

В первой версии у меня не будет ничего кроме контракта на solidity
и я не могу например на сервере по крону запускать скрипт который бы обратился в блокчейн эфириума и вызвал функцию "вычислить победителя и выплатить".
Поэтому думаю в контракте в fallback функцию добавить проверку текущего времени и если с момента прошлого розыгрыша прошло более 24 часов, то производить розыгрыш.

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