Пользователь
В последнее время смарт-контракты широко применяются в сети Ethereum в основном для проведения ICO и управления выпущенными токенами. Такие контракты существуют столько, сколько необходимо для обслуживания проектов, при этом месяцами обеспечивают бесперебойное взаимодействие с тысячами клиентов. Будем называть их долгосрочными смарт-контрактами.
Однако определённые задачи требуют, чтобы контракт выполнялся буквально за минуты, после чего он становится не нужен. Причём для каждого пользователя могут понадобиться особые параметры, реализовывать их в рамках большого контракта нецелесообразно. Такие контракты будем называть краткосрочными. Рассмотрим их более подробно в этой статье.
Идея управляемых токенами реестров (TCR) зародилась в блокчейн-сообществе не менее года назад. По крайней мере, эта статья была опубликована автором еще в сентябре 2017 года. А недавно я был на конференции DappCon 2018 в Берлине и увидел большой интерес к этой теме, а также несколько ранних набросков на основе TCR. Поэтому предполагаю, что пик интереса еще впереди.
Мне TCR-контракты представляются крайне интересными, поскольку они являют собой пример наиболее простой замкнутой системы, управляемой децентрализованно и на основе экономических стимулов. Если немного пофантазировать, становится понятно, что на основе этой идеи можно децентрализовать очень многое, возможно даже всё в нашей социально-экономической жизни. И это уже не просто галлюцинации сумасшедших криптанов, а вполне неплохо сформулированный протокол. Более подробно читайте под катом.
По материалам моего доклада на конференции «Цифровая трансформация» в Москве 16 апреля 2018 г
Мне интересно, как работает блокчейн. Не только какие там алгоритмы, криптография, платформы и криптовалюты. Для меня блокчейн — не только технология, но и новый вид жизни, новая вселенная. Если вы в этом сомневаетесь, посмотрите на этот граф распродажи токенов Aragon:
Все эти адреса, смарт-контракты, токены постоянно взаимодействуют друг с другом, и за ними стоят действия людей, организаций и роботов. Без этого взаимодействия блокчейн и криптовалюты не имели бы никакого смысла и ценности.
Как работают бизнесы в блокчейн, что там делают люди и роботы — эти вопросы заставили меня заняться исследованием блокчейна.
Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.
Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".
Gotcha — корректная конструкция системы, программы или языка программирования, которая работает, как описано, но, при этом, контринтуитивна и является причиной ошибок, поскольку её легко использовать неверно.
В языке Go есть несколько таких gotchas и есть немало хороших статей, которые их подробно описывают и разъясняют. Я считаю, что эти статьи очень важны, особенно для новичков в Go, поскольку регулярно вижу людей, попадающихся на те же грабли.
Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?
И ответ оказался довольно прост. Я просто очень вовремя прочёл несколько хороших статей о внутреннем устройстве структур данных в Go и прочих деталях реализации. И этого, вполне поверхностного на самом деле, знания было достаточно, чтобы выработать некоторую интуицию и избегать этих подводных камней.
