и ощутить гору гемора

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

как можно предположить что они не будут подписывать оба форка, если они уже сделали два форка?

Незаметно вставить - не наша тема

Ммм, а это откуда?

там же своя какая-то целая наука с кучей локов. Узкая область знаний о том как это всё делать правильно. Я от неё далёк.

Привет! Я боюсь быть неточным. По моему тут вопросо в субъективности - т.е. с точки зрения какого участника оцениваются C + A + P свойства. С точки зрения пользователя, который ждет когда сеть договорится о его транзакции - Availability у PoW биткоина и эфира нет - гарантируется только что если транзу включат в блок, то консистентно (сеть придет к одному и тому же состоянию UTXO) и PT (будет детерминистично выбран один и только один форк). А со стороны софта ноды имеет место AP , так как достаточно просто провалидировать блок и накатить его на state database, и плевать что с другими нодами не будет Consistency. В общем я просмотрел несколько статей - все пишут по разному, хрен его знает как правильно. Одно точно понятно - сразу все точно не удастся достичь

Более строгая модель - что у тебя не какие-то там разные майнеры, а один майнер. Хочет - форкает, не хочет - не форкает. Интересно понять почему он не форкает.

Та вот если два форка существует — то ты и задетектишь, что подписей не хватает.

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

Точно! Спасибо! Чо-то сегодня день дня Радио, сегодня коллеги Угорщину вспоминали.

ну вот либо ты делаешь глобальный лок, и все жутко тормозит, либо делаешь глобальную append-only очередь из операций, которые сделаны на основе best effort (некоторые могут конфликтовать). И затем ты можешь реплицировать этот лог на независимые N машин, которые могут отставать с разным лагом от Истины, заключенной в процессинге всей очереди.

Когда ты делаешь платеж через одну из машин, она делает быструю локальную проверку, есть ли деньги (чтоб не писать в очередь почем зря), и если ей кажется что есть, засылает транзакцию в очередь. А вот отвечает она тебе, что все ок - после того как подсосала всю очередь до того места, где твоя транзакция. И, естественно, она выкидывает конфликтующие транзакции детерминированным образом. Если дошла до твоей и она не конфликтует - значит, конфёрмд. А если нет - то отлуп.

Так ты можешь отреплицировать свою БД на чтение и записью не тормозить все реплики.

только смотри-ка - получился блокчейн!

спасибо за комментарий :) я вот только не уверен насчет "сли транзу включат в блок, то консистентно" - может же быть реорг, причем с т.з. теории - с любой глубины

в принципе, майнеры могли бы таймстемпить и невалидные транзакции (тогда spv не работал бы), но у этого подхода есть другая проблема - они их хоть и быстрее могут валидировать (цпу экономить), но тогда немайнеры могут спамить сеть в нулевым риском

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

Опять теория - кто-то пробовал делать селфиш майниг ? или может историю вспомнят когда таки пытались атаковать. в теории - атакуемая система сидит и не реагирует, а на практике противодействует. и 33% сеть не захватишь, максимум парочку транзакций можно дабл спенднуть.
и на прадктике 33% ресурсов не могут создадут стабильную цепочку длинее чем 66% ресурсов на тойже сложности, в сети с массовыми валидаторами нодами. это тоже то что часто люди в теории забывают.

В PBFT - 33% порог атаки это да.
https://vitalik.ca/general/2018/08/07/99_fault_tolerant.html

Самый высокий риск сейчас у алькойнов, которые используют алгоритмы на которых есть более высокий хешрейт Scrypt/Sha256...  например для атаки BCH, BCH-SV - среднему пулу достаточно только на время переключить мощности, пул при этом не сильно теряет и не сильно рискует, и не рискует потерять оборудование, только малую часть ресурсов.