Предполагаю что оно, лекарство, есть. Но искать его надо снаружи этой ситуации. Для этого надо выбраться немного из ямы и взглянуть сверху. Одно это дорогого стоит.
Вы пишете: отладка WebAssembly — это сложный вопрос…
Как все таки выглядит процесс разработки целиком? Можно ли ошибки находить и исправлять прямо в браузере ( как при разработке на JS ). Есть ли плагины типа FireBug что ли для того чтобы видеть что там происходит в программе? Как увидеть значения переменных?
Кроме браузера — эту программу можно отладить как то еще? В дебагере каком то запустить?
Если у вас сильно меньше 7 миллионов, то, наверно, много
С другой стороны, такие контракты типа адресов A имеют чисто служебное использование и как экспонаты вряд ли интересны
С адресами типа 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?
Так как вопроса два, отвечу отдельными комментариями
про адреса типа А если я правильно понял можно узнать запросом типа:
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 миллиона, то есть примерно каждый пятый контракт создан другим смарт контрактом и вызывался исключительно другими смарт контрактами
Что это за звери можно посмотреть запросом ( здесь учитывается тот факт, что создание смарт контракта в базе хранится такой же записью, как и любой другой вызов):
Да, внутренние транзакции ( traces ) разбирались и записывались в хранилище. Второй вопрос не до конца понял, но думаю что тоже да. Действительно, есть контракты, которые используются только как механизм связывания транзакций ( типа как подпрограмма ). Конечно, это все есть
А может быть, проблема не в самом коде ответа 444 а в том, как nginx обрабатывает ответ? Возможно, что он ведет себя не «очень хорошо» с точки зрения браузера. Эту версию можно проверить, взяв любой другой веб сервер и ответить 444.
Глупость сморозил, нет такого кода, проверять нечего.
Сравнивали ли вы с другими альтернативами, например с SuperSet? Судя по картинкам они функционально похожи, и от того же Apache. И в этой категории есть также множество коммерческих продуктов — почему все таки Zeppelin?
Собственно, тем инструментом, который в статье описан. Заходите на сайт bloxy.info, вбиваете в строке поиска Aragon. Из списка найденных токенов выбираете первый — у которого транзакций больше.
Переходите на закладку Graph. Сделайте Full screen и zoom чтобы видеть всю картину.
Далее найдите шестеренку ( это смарт-контракт ), к которой ведут самые толстые зеленые стрелки ( это множество вызовов транзакций смарт-контракта). оттащите его в сторону и double click мышью. Смарт контракт раскроется. Вы увидите теперь, что от него идет толстая красная стрелка ( это много переводов денег ) другому смарт контракту. Кликните на него — появится стрелка толстая к голубой свинье.
Голубая свинья — это мультиподписной кошелек ( MultiSig) на котором копились деньги этого ICO.
Теперь у вас тоже получилось сделать такую картинку как в статье. Можно так исследовать другие ICO и вообще все, что происходит в новом мире. Кстати, диаграммы есть и на уровне индивидуальных транзакций, они тоже крайне интересны.
config.active_record.belongs_to_required_by_default = false
?
Где лекарство?
Как все таки выглядит процесс разработки целиком? Можно ли ошибки находить и исправлять прямо в браузере ( как при разработке на JS ). Есть ли плагины типа FireBug что ли для того чтобы видеть что там происходит в программе? Как увидеть значения переменных?
Кроме браузера — эту программу можно отладить как то еще? В дебагере каком то запустить?
С другой стороны, такие контракты типа адресов A имеют чисто служебное использование и как экспонаты вряд ли интересны
По ETL — да, это нода Parity с чтением по RPC API
Поэтому этот контракт был учтен
А какой из этого вывод можно сделать?
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?
про адреса типа А если я правильно понял можно узнать запросом типа:
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 миллионов. Что достаточно много, учитывая что всего смарт контрактов:
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
Бедняга общался только с роботами, обычные адреса ( типа люди? ) только использовались как аргументы в вызовах):
Глупость сморозил, нет такого кода, проверять нечего.
Переходите на закладку Graph. Сделайте Full screen и zoom чтобы видеть всю картину.
Далее найдите шестеренку ( это смарт-контракт ), к которой ведут самые толстые зеленые стрелки ( это множество вызовов транзакций смарт-контракта). оттащите его в сторону и double click мышью. Смарт контракт раскроется. Вы увидите теперь, что от него идет толстая красная стрелка ( это много переводов денег ) другому смарт контракту. Кликните на него — появится стрелка толстая к голубой свинье.
Голубая свинья — это мультиподписной кошелек ( MultiSig) на котором копились деньги этого ICO.
Теперь у вас тоже получилось сделать такую картинку как в статье. Можно так исследовать другие ICO и вообще все, что происходит в новом мире. Кстати, диаграммы есть и на уровне индивидуальных транзакций, они тоже крайне интересны.
Удачи!