Topic: Изучаем Solidity (Read 588 times)

Классно, что на это не закончили. Я тоже кстати  изучаю java и solidity

Вы все правильно делаете, не останавливайтесь.
Но все же не забывайте иногда выкладывать продолжение истории.
Я и так случайно на нее наткнулся, пролистывая форум на год назад.
Это поучительно и познавательно.
Удачи.

Меня убедили в том, что на одном solidity далеко не уедешь.
Крайне сложно найти клиента которому бы нужен был бы чисто смартконтракт, а не сайт\приложение + смартконтракт.

И в январе я решил что надо изучить Java.
Вот все еще изучаю.
Сначала проходил курсы на hexlet, все что там тогда было по java, курс закончился, а я еще был далек от того чтобы сделать самый простенький сайт на java.
Потом я еще почти 3 месяца занимался на javarush.
Чтож, это было весьма полезно, теория полученая на hexlet отлично дополнилась огромной кучей задачек которые я решал тут сотнями.
Я добрался до 15го уровня javarush
Но.. до java-web было все бесконечно далеко, и в будущих уроках как то не проглядывалось что меня начнут этому учить.

Я пошел на форум программистов и нашел себе учителя, на java-web.
Занимаемся уже 2 недели, и конечно с живым человеком обучение идет гораздо интереснее чем по курсам.
Мне кажется что я уже близок к продакшену и за пару месяцев напишу первый проект который у меня был запланирован.

Отличная тема, действительно интересно - ждём продолжения.
Сам хотел солидол изучать, надо написать пару смарт контрактов для тестирования.

С удовольствием прочитал данный топик.
Как хороший рассказ. Жаль что оборвался.
Интересно было бы узнать конец истории....

Игрался с рандомом, написал вот такой код:

Экспериментально выяснил, что когда вызываю функцию изменяющую контракт, то есть объявленную без constant то в блокчейне Remix возникает новый блок.
Такие функции Remix отображает красными квадратиками.
function getWinnerNumber() вычисляет победителя, но почему то не хочет Remix отобразить результат из нее.
Сделал поэтому printWinnerNumber() она чисто отображает результат.
Жмем последовательно, видим, что по хешу блока выдаются разные случайные значения в заданном диапазоне.

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

Пишу читаю, и вдруг я вспомнил про code convetions.
Решил что надо глянуть как принято в solidity писать, и писать так, а не как попало.
Мда, там многобукв
Пока запомню и внедрю самое важное:

Функции надо называть  разделяя слова заглавными буквами, типа function thisFunctionHasLotsOfArguments()
а в переменных использовать подчеркивания long_variable

И использовать пробелы а не табы (wtf?!), ну ок, стандарт есть стандарт.

Для розыгрыша нужна функция в которую надо передать полное количество билетов участвующих в розыгрыше и на выходе получить случайный номер билета.
random(max_ticket_number);


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

Итак мы хотим функцию random куда надо передать max_ticket_number и на выходе целое число получить от 1 до max_ticket_number
Я решил попробовать извлечь случайные данные из block.blockhash текущего блока.
Вот такой код я написал в Remix
Хеш беру не текщего блока а предидущего, тк текущий выдает одни нули, а предидущий дал
0x18676e992055c057538d59b378271bb4eacdb7f6abf9e815fd63255dc11166b6
Выглядит очень случайно!

pragma solidity ^0.4.13;
contract Random {
    function get_block_number() public constant returns (uint) {
        return block.number;
    }
        function get_blockhash() public constant returns (bytes32) {
        return block.blockhash(block.number);
    }

}

Осталось перевести byte32 в uint и произвести деление с остатком.
Ну и протестить на случайность, взяв такой рандом за последние 1000 блоков и посмотреть какие он выдаст цифры от 1 до 10 и посмотреть нет ли отклонений выдаче.

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

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

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

Думал над архитектурой данных своей тестовой лотереи.
Пришел к мысли что надо сделать фиксированную цену "лотерейного билета".
Вопервых, цена билета должна быть значительно выше средней комиссии за транзакцию эфира, ну хотя
бы в 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й пункт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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