Пожалуйста, перелистайте вместе со мной на шестую главу белой книги
Название очень простое: «Криптографические примитивы». Именно здесь лежит настоящая основа приватности @Dusk
То, о чём мы говорили раньше — консенсус и модель транзакций — на самом деле дом, построенный поверх этого фундамента
Я заметил очень очевидный закономерный паттерн: почти каждый «компонент» устроен как «двухколейная конфигурация»
Хеш используют Blake2b для универсальных вычислений, а для ZK-доказательств дополнительно ставят Poseidon; подписи — Schnorr для повседневных сценариев, и сверху BLS для агрегируемых подписей; даже кривые разделены на две: JubJub отвечает за обычные операции, а BLS12-381 — за спаривания
Моё предположение: это не «складирование всего подряд», потому что требования к хешу в ZK-дружественных и обычных сценариях вообще не одинаковые. Если пытаться впихнуть одно и то же решение, будет плохо с обеих сторон, поэтому просто держат две отдельные реализации
Больше всего меня впечатляет скрытый адрес: он не даёт вам один фиксированный адрес, который можно использовать до конца, а генерирует одноразовый публичный ключ прямо на месте каждой транзакции — на основе обмена ключами Диффи–Хеллмана
Приёмник показывает только public spend key. Отправитель берёт случайное число r, вычисляет одноразовый публичный ключ и отправляет средства. Приёмник затем сверяет транзакцию своим view key, чтобы понять: «это отправлено мне». А чтобы потратить, уже нужно задействовать secret spend key
Смотри/Принимай/Трать — три ключа, каждый отвечает за свою часть. Я считаю, что это гораздо умнее, чем «один адрес использовать до скончания веков»: никто на блокчейне не сможет связать ваши многочисленные поступления в одну цепочку
В схеме обязательств используется Pedersen: c = v·G + b·H, где G и H — два генератора с неизвестной взаимосвязью. Так можно скрыть сумму и при этом нельзя потом «откатить» и подменить число
И шифрование тоже разнесено по инструментам: ElGamal занимается асимметричным, а Poseidon-SpongeWrap — симметричным
Даже с Merkle-деревьями не халтурят: универсальную структуру хешируют Blake2b, а любым структурам, которые нужно скармливать ZK-доказательствам, дают Poseidon. Одна и та же идея проводится до конца
Честно говоря, когда видишь такой уровень детального распределения ролей, немного удивляешься
Большинство белых книг на этом уровне просто пишут одну фразу: «используем общепринятые в индустрии решения» — вскользь, без #dusk $DUSK @Dusk
Название очень простое: «Криптографические примитивы». Именно здесь лежит настоящая основа приватности @Dusk
То, о чём мы говорили раньше — консенсус и модель транзакций — на самом деле дом, построенный поверх этого фундамента
Я заметил очень очевидный закономерный паттерн: почти каждый «компонент» устроен как «двухколейная конфигурация»
Хеш используют Blake2b для универсальных вычислений, а для ZK-доказательств дополнительно ставят Poseidon; подписи — Schnorr для повседневных сценариев, и сверху BLS для агрегируемых подписей; даже кривые разделены на две: JubJub отвечает за обычные операции, а BLS12-381 — за спаривания
Моё предположение: это не «складирование всего подряд», потому что требования к хешу в ZK-дружественных и обычных сценариях вообще не одинаковые. Если пытаться впихнуть одно и то же решение, будет плохо с обеих сторон, поэтому просто держат две отдельные реализации
Больше всего меня впечатляет скрытый адрес: он не даёт вам один фиксированный адрес, который можно использовать до конца, а генерирует одноразовый публичный ключ прямо на месте каждой транзакции — на основе обмена ключами Диффи–Хеллмана
Приёмник показывает только public spend key. Отправитель берёт случайное число r, вычисляет одноразовый публичный ключ и отправляет средства. Приёмник затем сверяет транзакцию своим view key, чтобы понять: «это отправлено мне». А чтобы потратить, уже нужно задействовать secret spend key
Смотри/Принимай/Трать — три ключа, каждый отвечает за свою часть. Я считаю, что это гораздо умнее, чем «один адрес использовать до скончания веков»: никто на блокчейне не сможет связать ваши многочисленные поступления в одну цепочку
В схеме обязательств используется Pedersen: c = v·G + b·H, где G и H — два генератора с неизвестной взаимосвязью. Так можно скрыть сумму и при этом нельзя потом «откатить» и подменить число
И шифрование тоже разнесено по инструментам: ElGamal занимается асимметричным, а Poseidon-SpongeWrap — симметричным
Даже с Merkle-деревьями не халтурят: универсальную структуру хешируют Blake2b, а любым структурам, которые нужно скармливать ZK-доказательствам, дают Poseidon. Одна и та же идея проводится до конца
Честно говоря, когда видишь такой уровень детального распределения ролей, немного удивляешься
Большинство белых книг на этом уровне просто пишут одну фразу: «используем общепринятые в индустрии решения» — вскользь, без #dusk $DUSK @Dusk