Обновить

Блокчейн глазами разработчика: append‑only база данных, за запись в которую платят

Уровень сложностиПростой
Время на прочтение8 мин
Охват и читатели4.9K
Всего голосов 2: ↑1 и ↓1+2
Комментарии8

Комментарии 8

никто — включая владельцев инфраструктуры — не может переписать историю

Вы точно понимаете, что такое «консенсус», и как он реализуется на практике?

Вопрос по делу, но это сознательное упрощение: статья вводная, для разработчиков, которые блокчейн ещё не трогали, и консенсус в ней честно вынесен за скобки одной фразой — иначе было бы +2000 слов.

Если строго, на вашем уровне разговора: цепочка хешей делает подмену истории лишь обнаружимой (как в git), а «не может переписать» обеспечивает уже консенсус — для атаки нужно большинство стейка, а откат финализированных блоков стоит слэшинга минимум трети всего стейка. То есть точнее не «невозможно», а «обнаруживается всеми и стоит дороже, чем приносит». «Владельцы инфраструктуры» в этом абзаце — операторы узлов и RPC-провайдеры: отдавать искажённые ответы своим клиентам такой оператор может, переписать историю для сети — нет.

PoS, финальность и слэшинг разберу отдельным материалом.

Всё примерно так, да. Но главный смысл существования блокчейна не в этом. А в том, что это распределённая система, которая работает по определённым правилам, которой можно доверять. С оговорками, понимая как она работает. В смарт-контрактах могут быть уязвимости, как и везде.

Сложно представить, чтобы открытый в интернет postgres с правами на запись, оставался безопасным местом.

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

А "открытый в интернет postgres с правами на запись" - отличный образ: это ровно пункт 1 статьи и причина, почему блокчейну вообще нужен консенсус.

Скорость записи

десятки тысяч TPS (Postgres)

~15–30 TPS в базовом слое (Ethereum)

Дочитал до этого момента и дальне не стал. Во‑первых, на хабре запрещено публиковать сгенерированные и/или обработанные LLM статьи (пункт 4 правил, могут выдать бан).

Вдвойне плохо публиковать непроверенные материалы. Про всего лишь десятки тысяч TPS у Postgres — это даже не смешно, равно как и у Ethereum (хотя не понятно почему именно с ним и только с ним сравнение), но давайте посчитаем вместе: блоки с gaslimit до 60M единиц газа, перевод ether требует 21 000 газа, выходит до 2857 переводов ether в блоке, которые в том числе используются для анкоринга, например. С учётом скорости генерации блоков это в худшем случае ~240 TPS — выходит какой‑то слишком уж большой отрыв с числами из статьи и это без учёта работы с blob, которая как раз максимально приближена к работе с БД. Числа по TPS явно занижены и судя по всему основываются на очень старых материалах в обучающей выборке LLM, когда TPS Postgres действительно был всего десятки тысяч, а Ethereum — 15–30 транзакций.
Перечитайте, пожалуйста, статью и пишите без использования LLM (или как минимум переписывайте руками с использованием норм орфографии русского языка и фактчекингом) ‑ там ещё много моментов, что было бы хорошо поправить. Но за старания респект и плюсик в карму, пишите ещё, но сами.

По цифрам вы правы - спасибо за пересчёт. Лимит газа действительно уже 60M, потолок на простых переводах ~240 TPS. Справедливости ради к самому числу: в реальной смешанной нагрузке сеть и сегодня держит ~25 TPS (около 2,2 млн транзакций в сутки), так что «15–30» как оценка живого потока недалеко от истины.

Сравнение именно с Ethereum - потому что дальше планирую разбирать именно EVM-стек; у L2 и blob-пространства арифметика своя, и согласен, что blob — ближайший аналог «работы с БД», до него ещё доберусь.

UPD в статье с вашим ником. Спасибо за комментарий - это отличный урок на будущее.

Справедливости ради к самому числу: в реальной смешанной нагрузке сеть и сегодня держит ~25 TPS (около 2,2 млн транзакций в сутки), так что «15–30» как оценка живого потока недалеко от истины.

Кстати, хорошая тема для потенциального исследования, как батчинг через MultiSend и кастомные контракты для батчинга на это повлияли. Потому как 10 транзакций можно (и нужно!) запихнуть в один вызов к MultiSend или ещё какому кастомному роутеру, где атомарность на самом‑то деле не нужна, но батчинг позволяет сэкономить газа и как следствие кажется, что число транзакций сократилось (средний размер правда вырос),‑ вполне себе приводит к падению метрики «число обработанных транзакций» при реальном росте обработки полезной нагрузки (я бывает вообще могу почти целый блок своим батчем забить изредка на каскаде ликвидаций). В общем да, наверное нужно отказываться просто от метрики TPS (вопрос лишь в том, что можно было бы взять на смену приближенное по смыслу).

Да, батчинг ломает TPS как метрику начисто. По-моему, честнее всего газ в секунду: он меряет выполненную работу, а не штуки транзакций. Blob-пространство тогда считается отдельно своим газом. Один только минус: непосвящённому «60M газа за 12 секунд» продать сложнее, чем «25 TPS» - поэтому TPS, кмк, переживёт нас всех.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации