Pull to refresh

Comments 53

Почитайте про hyperledger.
Это блокчейн, который разрабатывают IBM, Intel, RedHat и прочие.
Представьте себе, например, несколько взаимодействующих компаний: поставщики услуг, комплектующих, производства и продажа. Сейчас каждая компания отделена от другой компании и имеет свою собственную бухгалтерию. Передача товаров по накладной и счетам фактурам. Работы по акту о выполненных работах. Весь документооборот от разных компаний теоретически можно было бы сшить в единый блокчейн, где одна компания или подразделение — это одна нода.
В России очень многие используют 1С бухгалтерию. Думаю если 1С не реализует такую супер бухгалтерию, то ее сделает кто-то другой и выиграет на этом.
Весь документооборот от разных компаний теоретически можно было бы сшить в единый блокчейн, где одна компания или подразделение — это одна нода.

Технически — да, можно. Но какой практический смысл этого? В электронном документообороте между компаниями напрочь отсутствует потребность в наличии единой и неизменяемой базы документов. Наоборот, участники обмена нуждаются в том, чтобы их взаимодействие оставалось полностью приватным и абсолютно все сведения должны быть доступны только непосредственным контрагентам. А также в том, чтобы была возможность вносить коррективы «задним числом», без сохранения какой-либо истории изменений.
Очень даже есть смысл. Вносить коррективы задним числом — это хорошо для бухгалтера, который химичит, но не очень хорошо владельцу бизнеса.
UFO just landed and posted this here
Кем физически определяются права бухгалтера и логирование?
Администратором? Вы полностью доверяете администратору? Насколько полностью?
Администратор ведь может быть в сговоре с бухгалтером, потереть логи и вообще перед увольнением оставить «скрипт с часовым механизмом».
Да, может. Но, скажем так, разве эта ситуация требует борьбы с ней с помощью блокчейна? Бухгалтер в сговоре с админом и в блокчейн может накидать липовых документов при желании.
Нет, не сможет, даже в сговоре с админом. Как раз в этом ключевое отличие блокчейна от БД. Необходимость подписей не позволит сделать «липовые» транзакции, а анкоринг не позволит накидать их задним числом.
А что мешает админу нагенерировать себе ключи с таким же описанием в сертификате, как у должностных лиц, и навешать им нужные права, вплоть до создания смарт-контрактов под них? Он же админ :) Другое дело, что в компании должен быть ещё и security officer, и всё такое… но вся эта инфраструктура есть и прекрасно работает и без блокчейна, в тех компаниях, где внедрен электронный документооборот.
Это уже не говоря о том, что мы рассуждаем, что он там в сговоре с бухгалтером теоретически что-то может сделать, при этом даже не задумываясь, что именно такого, и зачем вообще это им затевать? Ведь речь-то идет о групповом сговоре для совершения уголовного преступления.
Админу будет мешать то, что описанной вами ситуации в принципе не должно быть, если мы все-таки решили строить инфраструктуру на блокчейне (правильно).

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

В случае с блокчейном все должно быть вывернуто наизнанку. Утрировано, директор – это тот, кто владеет секретным ключем, а его публичный ключ записан в генезис блоке (и да, тут можно пуститься в длинную конструктивную дисскусию о том, насколько это применимо к реальному миру и что делать в случае компрометации ключей). Никакой администатор ни под каким предлогом не должен иметь возможности «нагенерировать себе ключи» других должностных лиц. Каждый учасник самостоятельно генерирует свой приватный ключ на том физическом устройстве, которому он доверяет.

Поскольку ключевая цель использования блокчейна – децентрализация, то и управление инфраструктурой блокчейна должно происходить децентрализовано. Проще говоря, нет никакого смысла разворачивать блокчейн из 10 нод, если всеми нодами управляет один и тот же админ. Такая сеть по своим свойствам безопасности будет эквивалентна приватному блокчейну с одним узлом (что на самом деле тоже может иметь смысл). Так что в худшем случае администратор может саботировать работу, нарушив работу одного из узлов, что не должно приводить к заметной деградации системы в целом.

Еще одним полезным свойством блокчейна является то, что в случае если кто-то из учасников будет не добросовестно пользоваться своими правами (например бухгалтер или админ), он не сможет замести следы, просто почистив логи, как в случае с обычной БД. Да, даже админ с root правами, до тех пор, пока осталась хоть одна правильная реплика блокчейна хоть где-нибудь. Тем самым всегда остается возможность разобратся в произошедшем пост фактум, и вероятность уголовного наказания сильно увеличивается, а потому соблазн рискнуть что-то нахимичить – стремится к нулю.
Каждый учасник самостоятельно генерирует свой приватный ключ на том физическом устройстве, которому он доверяет.

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

Да, но ведь корпоративная среда централизована, и это не архитектурное решение, а бизнес-требование.
UFO just landed and posted this here
UFO just landed and posted this here
Если вы не доверяете главному бухгалтеру и сисадмину — блокчейн вам уже не поможет :)
Возможности бухгалтера ограничены тем, что позволяет его интерфейс. Вносить коррективы задним числом необходимо в первую очередь владельцам и руководству бизнеса. Это регулярно возникающая ситуация во взаимоотношениях компаний, когда условия уже заключенных сделок в процессе работы изменяются таким образом, что нужно не корректировать предыдущий вариант, а целиком его заменить в истории, причем так, чтобы не было следов, ни для конкурентов, ни для фискальных органов.
> В электронном документообороте между компаниями напрочь отсутствует потребность в наличии единой базы документов.

Вы ошибаетесь. Вспомните об этом, когда банк будет возвращать вам забракованный платеж «до трех рабочих дней».

Блокчейн может обеспечить консистентное представление о состоянии данных без необходимости взаимного доверия между учасниками, в отличии от классических БД. Это значительно упрощает взаимодействие между учасниками системы.

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

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

> А также в том, чтобы была возможность вносить коррективы «задним числом», без сохранения какой-либо истории изменений.

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

Может. Но в случае обмена данными между корпоративными клиентами взаимное доверие ведь и так есть по умолчанию, ведь легитимность участников подтверждена данными государственной регистрации.
Вносить коррективы «задним числом» плохо всегда, особенно если в системе задействованы несколько распределенных учасников.

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

Спасибо, вы вызвали у меня улыбку этим вечером. :) Это конечно идеологический вопрос, но есть два разных понимания слова trust: «доверяю, потому что вынужден верить» (есть государственная регистрация, сертификат, подпись нотариуса, хорошая репутация, отутствие альтернаты) и «и доверяю, потому что есть математическое доказательство корректности». Почему-то считается, что вы должны доверять банкам/компаниям/государству в первом смысле этого слова, точно так же, как вы доверяете своей семье и близким. Блокчен позволяет перевести взаимодействие агентов из первой плоскости во вторую, когда вы доверяете контрагенту потому что знаете что у него технически нет возможности вас обмануть.

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

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

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

В идеальном мире блокчейн приводит к ситуации вида: «агенты, которые не доверяют друг другу, но могут безопасно взаимодействовать без регулирующего органа» (блокчейн по сути становится безпристрастным регулятором). На сегодняшний день скорее всего возможен только переходной вариант, в котором «юридический» регулятор – это еще одна роль в системе, со своими «уровнями доступа» и правами. Правила игры должны быть выстроены таким образом, чтобы добросовестным агентам не было нужды переписывать историю: требования – адекватные, ошибки – исправимые. Но этот вопрос уже лежит скорее в законодательной области, чем в технической.
Я честно, не могу понять, что значит «математическое доказательство корректности» в случае проверки легитимности контрагента. Вот если я вижу какие-то данные, подтвержденные госорганом, я могу понимать, что мой контрагент, к примеру, компания А. А вот если я вижу, что у меня есть электронная подпись в публичном блокчейне, где написано «компания А», то как я ей могу доверять? Математика мне ведь даст только уверенность, что при генерации ключей там в сертификате написали именно это название. Но без того же госрегистратора я понятия не имею, кто его написал, и можно ли ему доверять.
Рассматривайте приватный ключ как имя своей компании. Публичный ключ — как адрес хранения приватного ключа. Точку создания этих двух ключей — как первую успешную транзакцию под вашим именем. Адрес всем известен, но доступен для чтения только вам. Точка создания всем видна, и осталась в прошлом.
Можно до посинения угадывать кешь транзакции с вашим именем, без вашего согласия участвовать в процессе — она не действительна.
UFO just landed and posted this here
А как я могу его рассматривать в качестве имени моей компании, если он перед моими контрагентами меня никак не идентифицирует?
Живой человек, который будет выполнять какие-либо действия над документом, не сможет определить по ключу, настоящий он или поддельный. Вот допустим я сгенерировал ключ номер 0x5fff57262aa66b, обозначил его «Компания А», злой хакер в этот день сгенерировал ключ 0x4253aa33bcccr, обозначил его тоже «Компания А». Да, он не сможет видеть сделанные мной документы. Но ведь с точки зрения контрагентов блокчейна эти ключи равноценны, и хакер может эффективно делать фишинговые атаки со своим ключом, и небезуспешно вести с контрагентами (например, с теми, с которыми я ещё не работал) параллельный документооборот якобы от моего имени. Пока не будет единого доверенного центра, куда я должен буду принести мои официальные документы, и там мой сертификат подпишут своим корневым ключом.
и что вы мне перечислили компании, от этого не тепло — не холодно. как будто бедных людей в мире стало меньше. Вы находитесь в денежно — финансовой системе, только она имеет значение. Все что выше расписано модными словами «блокчейн» вселишь очередная коммерция, типа купи быструю транзакцию во обход банковской системе. Но без банковской системы, не какой стоимости у этого биткоина нету.
подскажите, а какая ценность у золота? и что делает деньги – деньгами?
В общем случае — определенная редкость того или иного ресурса и/или сложность его добычи может гарантировать предсказуемость общего объема ресурса на рынке. В таком случае его можно использовать как примитивное платежное средство, не опасаясь инфляции и манипуляции рынком. Ресурсом может быть что угодно, от камней определенного вида или редких ракушек и птичьих перьев до отдельных химических элементов, таких как золото.
Изначально редкостью определялась и номинальная стоимость этого золота как средства платежа, в грубом приближении равная стоимости его добычи, обработки и доставки на рынок (в т.ч. чеканки монет).

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

Суть многих споров вокруг блокчейна связана с конфликтом перечисленных выше определений «платежного средства». С одной стороны определенная часть общества приняла для себя криптовалюты в качестве средства платежа, и вложила в него в качестве «ресурса» определенный объем электроэнергии, вычислительных мощностей и денежных средств. С другой, государственные образования, которые традиционно отвечают за денежную систему, не могут эти самые криптовалюты толком контролировать, терять контроль над частью экономики не хотят, и часто не могут определиться, считать ли криптовалюты «деньгами», «товаром», или вообще не допускать их на легальный рынок.
Ссылка на саму разработанную систему отсутствует — значит пост не о рекламе сервиса. Технических деталей реализации — чуть более чем ноль, значит это не о том как это сделано. Ответа на вопрос «почему сломался миксер» — нет, даже сам объект миксера не распознан. В чем суть поста?
Я вижу в блокчейн не столько технологию или деньги, сколько новое общество. Беллетристики на эту тему написано много и я не хочу её повторять. Мне, как технарю, интересно при помощи точных инструментов это новое общество измерить, понять и научиться жить по его законам. Я сам понимаю идеалистичность этого подхода, но сам блокчейн в целом идеалистичен.

Ссылка на сайт где можно посмотреть все материалы, представленные в статье, есть — это bloxy.info. Про миксер там есть целая статья построенная в виде data dashboard . Миксер был выбран как один из примеров, потому что как объект он не существует. Это сообщество роботов, видимо, управляемое централизованно. В блокчейне эта централизация невооруженным глазом никак не видна, и единственный способ его найти — использовать методы аналитики и статистики. Вполне возможно, что таким же способом можно находить и другие аномалии, «сговора» и проявления централизации и авторитарности в блокчейн. Если научиться делать такую аналитику качественно и дать эти результаты на всеобщее обозрение, блокчейн станет более прозрачным, безопасным и в него больше будут верить.
Отличный сервис, только в самой статье надо было сразу на него ссылки дать.
Все кто пишет, что классическим архитектурам доверять нельзя, а блокчейну можно, как-то забывают о том, что владелец 50%+1 мощностей может поменять всю историю транзакций.
Этот риск немного ниже в крипте, хотя в основных криптах ТОП-3 владельца уже аккумулирували порядка 45%. Что им помешает объединиться для «великого кидка»?
А если говорить о блокчейне между компаниями, пусть таже ТНК, или о регуляторах, то там априори владение сконцентрировано изначально.

+ Как правильно было замечено автором, блокчейн — это не сама сеть, а люди и то, как / чем они взаимодействуют с сетью. Сколько уже было случаев взлома посредников, за счет чего компроментировалась вся сеть.

Так что единственное «преимущество» блокчейна — распределенность -> достоверность, под большим вопросом и ни чем не лучше в сравнении с грамотной организацией классической архитектуры.

Я не верю в блокчейн на столько же, на сколько сильно верит автор. И со мной солидарна статистика — блокчейн отстает уже на 2 года (!) в своей динамике роста, по сравнению с другими успешными хайп-технологиями-единорогами. ИМХО
но ведь старая ветка все еще будет доступна в блокчейне разве нет? Переписать то можно но скрыть факт перезаписи не получится. Ну и как только это вскроется так курс этой скомпрометированной валюты рухнет в 0.
Да, старая ветка называется Uncle и, конечно, сохранена в блокчейн. Атаки этого вида сильно активизировались за последний месяц, пример Bitcoin Gold и статья на эту тему.

Хотя эта уязвимость считается фундаментальной в классическом Proof of Work блокчейн, но сказать что она как то влияет на крипто-рынок, пока нельзя. Строго говоря, это не атака вовсе, а заложенная в протокол возможность. Анализировать её надо при помощи теории игр, например. Есть кстати сайт crypto51 с некоторыми расчетами по стоимости такой атаки.

Забавно что любой блокчейн рассматривается только с какими то токенами. Причем в подавляющем большинстве случаев единственное применение этих токенов — подзаработать создателю системы

С помощью какого инструмента отрисована сеть на первом скриншоте? Можно название, ссылку или любую инфо о продукте.
Собственно, тем инструментом, который в статье описан. Заходите на сайт bloxy.info, вбиваете в строке поиска Aragon. Из списка найденных токенов выбираете первый — у которого транзакций больше.

Переходите на закладку Graph. Сделайте Full screen и zoom чтобы видеть всю картину.

Далее найдите шестеренку ( это смарт-контракт ), к которой ведут самые толстые зеленые стрелки ( это множество вызовов транзакций смарт-контракта). оттащите его в сторону и double click мышью. Смарт контракт раскроется. Вы увидите теперь, что от него идет толстая красная стрелка ( это много переводов денег ) другому смарт контракту. Кликните на него — появится стрелка толстая к голубой свинье.

Голубая свинья — это мультиподписной кошелек ( MultiSig) на котором копились деньги этого ICO.

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

Удачи!
Ясно. Меня просто заинтересовал подобный функционал по построению сетей, но не с привязкой к криптовалютам и.т.п у нас нечто подобное реализовано на SAS Social network, но лицензии дорогие… мы ищем нечто похожее для построения сетей из опенсорса я и подумал, что здесь используется какой-то инструмент позволяющий строить сети на основе хранящихся данных в БД.
Вопрос только в том, какие у вас есть данные, в каком они виде и что вы хотите визуализировать. А инструментов тьма, включая opensource — тот же d3.JS отрисует, практически, что угодно.
Если нужна не просто отрисовка, а построение \ аналитика, то в Python и R есть готовые пакеты и визуализаторы.
Выбор инструмента, наверное, саме последний вопрос :)
Просмотрел аналитику по ERC721 и появилась мысль. Есть множество разнообразных бирж для покупки и продажи ERC20 токенов, даже прямо внутри блокчейна эфира. Но есть ли какой-то сервис единого обмена, покупки, продажи и аукционных торгов для 721? Просто мне кажется это может быть бутылочным горлышком для развития этого направления. И стоит задуматься над созданием общего инструмента для раширения оборота non-fungibility активов и как результат роста частоты их использования. Что-то типа биржи, но со своими правилами использования.
Такие биржи есть, например opensea и rarebits. Пока, конечно, там денег крипто-кот наплакал
посмотрел, там такой бред продается, и большей частью — те же котята. Нужно чтобы торговали тем, что имеет хоть какую-то ценность внешнюю.
А внутренние транзакции учитывались?
А адреса-контракты, которые не взаимодействуют с обычными адресами?

Да, внутренние транзакции ( traces ) разбирались и записывались в хранилище. Второй вопрос не до конца понял, но думаю что тоже да. Действительно, есть контракты, которые используются только как механизм связывания транзакций ( типа как подпрограмма ). Конечно, это все есть
Если контракт A создан другим контрактом, и если к А обращались только посредством других контрактов, то А может иметь код и положительный баланс.
На адрес Б можно перекинуть эфир с помощью инструкции suicide.
Чтобы найти контракт А в блокчейне, нужно трассировать каждую транзакцию посредством EVM, либо вытащить все адреса напрямую из базы geth или parity.
То же относится и к адресам типа Б.
Как я понял, вы трассировали каждую транзакцию.
Много ли адресов типов А и Б в блокчейне по сравнению с обычными контарктами и адресами?
Так как вопроса два, отвечу отдельными комментариями

про адреса типа А если я правильно понял можно узнать запросом типа:

SELECT countDistinct(smart_contract_address_bin)
FROM 
(
    SELECT 
        smart_contract_address_bin, 
        countIf(tx_hash_bin, dictGetString('smart_contract_by_address', 'contract_type', tuple(concat('0x', lower(hex(tx_from_bin))))) = '-') AS calls_count_from_regular_addresses
    FROM production.calls_sc 
    GROUP BY smart_contract_address_bin
    HAVING calls_count_from_regular_addresses = 0
) 

┌─uniqExact(smart_contract_address_bin)─┐
│                               4354435 │
└───────────────────────────────────────┘

1 rows in set. Elapsed: 16.317 sec. Processed 294.18 million rows, 29.12 GB (18.03 million rows/s., 1.78 GB/s.) 



Таким образом, их чуть больше 4 миллионов. Что достаточно много, учитывая что всего смарт контрактов:

SELECT countDistinct(smart_contract_address_bin)
FROM production.calls_sc 

┌─uniqExact(smart_contract_address_bin)─┐
│                               7054556 │
└───────────────────────────────────────┘

1 rows in set. Elapsed: 5.547 sec. Processed 294.18 million rows, 8.53 GB (53.04 million rows/s., 1.54 GB/s.) 


7 миллионов. То есть таких контрактов чуть больше половины всех.

Если отфильтровать те, которые хоть раз вызывались:
SELECT countDistinct(smart_contract_address_bin)
FROM 
(
    SELECT 
        smart_contract_address_bin, 
        countIf(tx_hash_bin, dictGetString('smart_contract_by_address', 'contract_type', tuple(concat('0x', lower(hex(tx_from_bin))))) = '-') AS calls_count_from_regular_addresses, 
        countIf(tx_hash_bin, dictGetString('smart_contract_by_address', 'contract_type', tuple(concat('0x', lower(hex(tx_from_bin))))) != '-') AS calls_count_from_smart_contracts
    FROM production.calls_sc 
    GROUP BY smart_contract_address_bin
    HAVING (calls_count_from_regular_addresses = 0) AND (calls_count_from_smart_contracts > 1)
) 

┌─uniqExact(smart_contract_address_bin)─┐
│                               1705989 │
└───────────────────────────────────────┘

1 rows in set. Elapsed: 14.006 sec. Processed 294.18 million rows, 29.12 GB (21.00 million rows/s., 2.08 GB/s.) 



То их все равно остается весьма внушительное количество — 1.7 миллиона, то есть примерно каждый пятый контракт создан другим смарт контрактом и вызывался исключительно другими смарт контрактами

Что это за звери можно посмотреть запросом ( здесь учитывается тот факт, что создание смарт контракта в базе хранится такой же записью, как и любой другой вызов):

SELECT 
    concat('0x', lower(hex(smart_contract_address_bin))) AS smart_contract_address, 
    countIf(tx_hash_bin, dictGetString('smart_contract_by_address', 'contract_type', tuple(concat('0x', lower(hex(tx_from_bin))))) = '-') AS calls_count_from_regular_addresses, 
    countIf(tx_hash_bin, dictGetString('smart_contract_by_address', 'contract_type', tuple(concat('0x', lower(hex(tx_from_bin))))) != '-') AS calls_count_from_smart_contracts
FROM production.calls_sc 
GROUP BY smart_contract_address_bin
HAVING (calls_count_from_regular_addresses = 0) AND (calls_count_from_smart_contracts > 1)
LIMIT 10

┌─smart_contract_address─────────────────────┬─calls_count_from_regular_addresses─┬─calls_count_from_smart_contracts─┐
│ 0xb97d780e5809c3afc41d8f46962b5b3b1cb5524c │                                  0 │                                2 │
│ 0x074716e53c1df67f0e1c66d459bfa1a434677e4f │                                  0 │                                8 │
│ 0x66dad44af901093090f360b643e4362a7e8861f2 │                                  0 │                                4 │
│ 0x47c3e2314f3c7875e7a2a205822e0d549263563d │                                  0 │                                2 │
│ 0x773b42543ba7cf82b4adec0fc3c90cb6839da536 │                                  0 │                                2 │
│ 0x63cf746c7af437343f29c0ed12429b55173e19a1 │                                  0 │                                3 │
│ 0x5a9a2cbfb7c7895a5c34b113b1707e92bb838119 │                                  0 │                                3 │
│ 0x18cd352bb4f648b2507690a361767affe86cb368 │                                  0 │                                2 │
│ 0xfdd9d2625e0948ad3aeb50430754368da5ed7dea │                                  0 │                                2 │
│ 0xe1d9b3687e6978ab161ac95f2a4d131ef8384f71 │                                  0 │                                2 │
└────────────────────────────────────────────┴────────────────────────────────────┴──────────────────────────────────┘



Вот например контракт: 0x074716e53c1df67f0e1c66d459bfa1a434677e4f

Бедняга общался только с роботами, обычные адреса ( типа люди? ) только использовались как аргументы в вызовах):



Вот например контракт: 0x074716e53c1df67f0e1c66d459bfa1a434677e4f


Нет, что-то неправильное ваша база выдала. Этот контракт имеет одну входящую транзакцию.
etherscan.io/address/0x074716e53c1df67f0e1c66d459bfa1a434677e4f

Остальные контракты из таблицы, судя по коду — это контракты-прокси.
Вот, например, 400 тысяч одинаковых контрактов.
etherscan.io/address/0x773b42543ba7cf82b4adec0fc3c90cb6839da536#code

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

А какой из этого вывод можно сделать?
Что контрактов типа А меньше 1.7 миллиона
С адресами типа B проще — это как я понял, получатели эфира от суицида смарт-контрактов:

SELECT
    countDistinct(transfer_to_bin) AS address_B_count,
    sum(value) / 1000000000000000000. AS ether_amount
FROM production.transfers_tx
WHERE (currency_id = 1) AND (tx_hash_bin IN
(
    SELECT tx_hash_bin
    FROM production.calls_sc
    WHERE dictGetString('signature', 'name', toUInt64(signature_id)) = 'suicide'
))

┌─address_B_count─┬──────ether_amount─┐
│           51293 │ 469014.4142188265 │
└─────────────────┴───────────────────┘

1 rows in set. Elapsed: 33.170 sec. Processed 603.01 million rows, 38.56 GB (18.18 million rows/s., 1.16 GB/s.)


Таких счастливчиков 51293 и получили они в сумме 469014.4142188265 ETH

А мне интересно — а что вам даст эта статистика по адресам типа A и B?
По адресам типа B просто интересно насколько популярен этот способ передачи эфира.

Я собрал базу всех контрактов, но не смог вытянуть из geth ноды контракты типа А. Вот и интересно, много ил я упустил.

А можно подробнее рассказать про стадию ETL?
Там измененная geth или paraty нода c хуками на запись базы?

Если у вас сильно меньше 7 миллионов, то, наверно, много
С другой стороны, такие контракты типа адресов A имеют чисто служебное использование и как экспонаты вряд ли интересны

По ETL — да, это нода Parity с чтением по RPC API
Я так понимаю, вызовы из раздела trace_?
А сколько времени занял весь процесс?
У меня так и не получилось завести полную ноду parity. Она выжирала всю доступную память и работала очень медленно при обращении через named pipes
Да, нужен trace. Процесс парсинга всей истории около 2 недель. По памяти вроде не было проблем, 32M должно хватать

В итоге удалось применить знания на практике?

Sign up to leave a comment.

Articles