Я в последнее время углубляюсь в whitepaper Dusk, и то, к чему я снова и снова возвращаюсь, — это вообще не часть про приватность.

Это про консенсус.

@Dusk использует Succinct Attestation с permissionless, комитетной моделью PoS. Тебе нужно 1 000 DUSK, чтобы делать стейк; каждый эпохальный период длится 2 160 блоков, а власть голосования взвешивается по стейку на основе 64 комитетных кредитов.

Вот эта последняя часть привлекла мое внимание.

Потому что если власть голосования взвешена по стейку, вопрос заключается не только в том, может ли сеть достичь консенсуса. Вопрос — как именно распределяется эта власть.

Интересны и пороги. Valid нужен 2/3, а Invalid, NoCandidate и NoQuorum — 1/2 + 1. После 16 неудачных итераций протокол может перейти в режим чрезвычайной ситуации.

На бумаге это звучит как разумный способ защитить живучесть.

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

А дизайн стимулов тоже продуман: 80% — генератору блоков, 10% — голосующему комитету и 10% — #Dusk , при этом за серьезное поведение, например двойное голосование, предусмотрено жесткое слэшинг-воздействие.

Затем есть транзакционный слой.

Moonlight — аккаунтная и публичная модель, а Phoenix использует ноты в стиле UTXO, деревья Меркла, nullifier’ы и ZK-доказательства.

Чем больше я смотрю на дизайн, тем интереснее становится не то, работают ли каждый компонент по отдельности.

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

Создает ли взвешенный по стейку кредит слишком сильную концентрацию со временем? И если большая часть валидаторов выходит из строя, достаточно ли надежен режим emergency, не открывая при этом еще один путь к форкам?

Вот это — часть архитектуры Dusk, которую я все еще хочу лучше понять.
$DUSK $TMX $DEBIT #XRPRallies44%InAWeek #CryptoFearGreedIndexHits74 #USStocksCloseHigherNvidiaGains2% #USBitcoinETFsExtendInflowsToSixthDay