STIGNING

Artigo Técnico

Arquitetura de custodia em sistemas financeiros distribuidos: Criptografia de limiar, MPC e contencao de falhas

Uma analise tecnica de sistemas de custodia distribuidos com criptografia de limiar, modelos adversariais bizantinos e protocolos de assinatura seguros a falhas.

17 de fev. de 2026 · Criptografia Fintech · 15 min

Publicação

Artigo

Voltar para o arquivo do blog

Briefing do artigo

Contexto

Programas de Criptografia Fintech exigem fronteiras explicitas de controle em fintech, cryptography, distributed-systems sob operacao adversarial e degradada.

Pré-requisitos

  • Baseline de arquitetura e mapa de fronteiras para Criptografia Fintech.
  • Premissas de falha definidas e ownership de resposta a incidentes.
  • Pontos de controle observaveis para verificacao em deploy e runtime.

Quando aplicar

  • Quando criptografia fintech afeta diretamente autorizacao ou continuidade de servico.
  • Quando comprometimento de componente unico nao e um modo de falha aceitavel.
  • Quando decisoes de arquitetura precisam de evidencia para auditoria e assurance operacional.

Resumo

In distributed financial systems, custody architecture defines the boundary of asset authority. While ledger systems preserve transactional invariants and ensure conservation of value, custody systems determine which entities are cryptographically capable of producing valid asset transfers. A failure in ledger logic may result in reconciliation complexity; a failure in custody design results in irreversible loss.

This article presents a technical and architectural analysis of custody systems built on threshold cryptography and Multi-Party Computation (MPC), focusing on formal security properties, Byzantine adversary assumptions, distributed signing protocols, crash safety, correlated failure domains, and practical implementations using FROST-based threshold signatures.

Custody is not key storage. It is adversarial distributed systems engineering.

From Centralized Keys to Distributed Authority

Let KK be a private signing key used to authorize asset transfers in an elliptic curve system such as ECDSA or Ed25519.

In a centralized model:

σ=Sign(K,m)\sigma = \operatorname{Sign}(K, m)

Where:

  • mm is the transaction message.
  • σ\sigma is a valid signature.

Security reduces entirely to the secrecy of KK.

If an attacker extracts KK, control over assets is permanently lost. Because blockchain-based transfers are irreversible, there is no rollback mechanism capable of undoing a malicious signature.

Distributed systems engineering operates under a different assumption: compromise is eventual.

Therefore, custody must satisfy:

Compromise of any single nodeCompromise of signing authority\text{Compromise of any single node} \ne \text{Compromise of signing authority}

This transforms custody from secret storage into distributed trust enforcement. In this model, the centralized baseline in Eq. (1) is intentionally replaced by the distributed authority condition in Eq. (2).

Threshold Cryptography and Secret Fragmentation

Instead of storing private key scalar xx directly, we distribute it using Shamir Secret Sharing.

Private key scalar: xZq\text{Private key scalar: } x \in \mathbb{Z}_q

Construct polynomial ff of degree (t1)(t-1) such that:

x=f(0)x = f(0)

Each participant ii receives:

xi=f(i)x_i = f(i)

No individual share reveals xx.

A threshold tt-of-nn system ensures:

  • Any subset of size tt can collaboratively produce a valid signature.
  • Any subset of size less than tt cannot reconstruct xx nor produce σ\sigma.

Security condition:

Number of compromised shares<t\text{Number of compromised shares} < t

Threshold selection encodes tradeoffs directly into system design.

Lower tt improves availability but weakens compromise resistance. Higher tt strengthens security but increases operational fragility.

This is risk modeling expressed mathematically.

Formal Adversary Model (Byzantine)

Assume a Byzantine adversary capable of:

  • Arbitrary message manipulation.
  • Adaptive node compromise.
  • Network delay and reordering.
  • Collusion among compromised nodes.

Let:

f=number of Byzantine nodesf = \text{number of Byzantine nodes}

Security condition:

f<tf < t

If ftf \ge t, signing authority is compromised.

Additionally, the signing protocol must ensure:

  • Robustness under up to (t1)(t-1) malicious nodes.
  • Unforgeability under partial compromise.
  • Bias-resistance in nonce generation.

Custody becomes a Byzantine fault-tolerant distributed protocol layered over cryptographic primitives.

The Signing Protocol as a Distributed State Machine

Distributed signing is interactive.

Each participant generates ephemeral nonce shares and contributes to a coordinated signing round.

Conceptually:

  1. Compromissos de nonce trocados.
  2. Nonce agregado calculado.
  3. Assinaturas parciais produzidas.
  4. Shares de assinatura agregados.

Final signature:

σ=(R,s)\sigma = (R, s)

The protocol must satisfy:

  • Concurrency safety.
  • Replay protection.
  • Crash atomicity.
  • Idempotency.

The signing protocol itself becomes a distributed state machine.

FROST: Efficient Threshold Schnorr Signatures

Modern custody systems frequently adopt Schnorr-based threshold schemes due to efficiency and simplicity.

FROST (Flexible Round-Optimized Schnorr Threshold Signatures) provides:

  • Two-round signing protocol.
  • Communication-efficient nonce commitment.
  • Bias-resistant nonce generation.
  • Provable security under discrete logarithm assumptions.

In Schnorr systems:

Y=xGY = xG

Verification condition:

sG=R+H(R,Y,m)YsG = R + H(R, Y, m)Y

Operational verification should remain traceable to Eq. (10) and Eq. (11) during runtime validation and incident review.

FROST produces signatures indistinguishable from centralized Schnorr signatures, ensuring blockchain compatibility.

Practical Example: frost-ed25519 (Rust)

Below is a simplified illustration using a FROST-compatible Rust library.

use frost_ed25519 as frost;
use rand::thread_rng;

fn threshold_sign(message: &[u8]) -> Result<frost::Signature, frost::Error> {
    let mut rng = thread_rng();

    let key_package = load_key_package();
    let pubkey_package = load_public_package();

    let (nonces, commitments) =
        frost::round1::commit(key_package.signing_share(), &mut rng);

    broadcast_commitments(commitments);

    let signing_package =
        frost::SigningPackage::new(commitments, message);

    let signature_share =
        frost::round2::sign(&signing_package, &nonces, &key_package)?;

    collect_signature_share(signature_share);

    let signature =
        frost::aggregate(&signing_package, collected_signature_shares, &pubkey_package)?;

    Ok(signature)
}

No full private key reconstruction occurs. Each node holds only its share. Final signature remains standard Ed25519-compatible.

Crash Safety and Atomic Signing

Consider node crash during signing round.

System must guarantee:

Incomplete signing roundNo valid signature produced\text{Incomplete signing round} \Rightarrow \text{No valid signature produced}

Intermediate nonce values must be ephemeral. Partial signatures must not be durable in reconstructible form. Retry must not reduce threshold requirement.

Custody must be crash-consistent by design.

Concurrency and Replay Safety

Custody must coordinate with ledger state.

Example validation:

fn validate_before_sign(tx: &Transaction, ledger: &Ledger) -> Result<(), Error> {
    if ledger.nonce_used(tx.account, tx.nonce) {
        return Err(Error::ReplayDetected);
    }

    if !ledger.balance_sufficient(tx.account, tx.amount) {
        return Err(Error::InsufficientFunds);
    }

    Ok(())
}

Ledger preserves value invariants:

entries(T)=0\sum \text{entries}(T) = 0

In practice, custody pipelines should validate this ledger invariant against Eq. (13) before issuing final signature broadcast.

Custody preserves authorization boundaries. Security is compositional.

Correlated Failure Domains

Threshold cryptography assumes independent shares. Operational correlation invalidates this assumption.

If shares reside in:

  • Same cloud account.
  • Same IAM boundary.
  • Same CI/CD pipeline.
  • Same secrets manager.

Compromise may become correlated.

Security principle:

Operational independenceCryptographic independence\text{Operational independence} \ge \text{Cryptographic independence}

Infrastructure separation, access isolation, and deployment segregation are mandatory.

Conceptual Signing Architecture

The custody signing flow can be visualized as:

                    +----------------------+
                    |  Transaction Proposal |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    |   Ledger Validation  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    |      Risk Engine      |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    |  Custody Coordinator  |
                    +----+--------+--------+
                         |        |        |
                         v        v        v
                    +--------+ +--------+ +--------+
                    | Node 1 | | Node 2 | | Node 3 |
                    | Share  | | Share  | | Share  |
                    +----+---+ +----+---+ +----+---+
                         \        |        /
                          \       |       /
                           \      |      /
                            v     v     v
                      +----------------------+
                      | Signature Aggregation |
                      +----------+-----------+
                                 |
                                 v
                      +----------------------+
                      | Broadcast Transaction |
                      +----------------------+

Ledger validation precedes custody signing. Risk policy constrains signing eligibility. Custody nodes collaboratively produce final signature.

Conclusao

Threshold cryptography transforms custody from centralized secret storage into distributed authority enforcement. FROST-based schemes provide efficient, bias-resistant threshold Schnorr signatures suitable for modern blockchain ecosystems. However, cryptographic guarantees alone are insufficient.

Custody must be analyzed under Byzantine adversary assumptions, implemented with crash-consistent protocols, and deployed across operationally independent failure domains. Ledger correctness preserves value invariants. Custody architecture preserves authority boundaries.

In distributed financial systems, control and correctness are inseparable. Without distributed custody, any system is ultimately controlled by whoever controls a single key.

Custody is where mathematics meets adversarial distributed systems engineering.

Referências

Compartilhar artigo

LinkedInXEmail

Navegação do artigo

Artigos relacionados

Criptografia Fintech

Autoridade de custodia em sistemas financeiros distribuidos: Reconstituicao de incidentes sob falha parcial

Uma analise formal de engenharia sobre criptografia fintech com enfase em reconstituicao de incidentes sob falha parcial e restricoes operacionais adversariais.

Ler artigo relacionado

Criptografia Fintech

Autoridade de custodia em sistemas financeiros distribuidos: Cadeias de evidencia de auditoria e operacoes verificaveis

Uma analise formal de engenharia sobre criptografia fintech com enfase em cadeias de evidencia de auditoria e operacoes verificaveis e restricoes operacionais adversariais.

Ler artigo relacionado

Criptografia Fintech

Autoridade de custodia em sistemas financeiros distribuidos: Sequenciamento de migracao para sistemas de alta garantia

Uma analise formal de engenharia sobre criptografia fintech com enfase em sequenciamento de migracao para sistemas de alta garantia e restricoes operacionais adversariais.

Ler artigo relacionado

Criptografia Fintech

Autoridade de custodia em sistemas financeiros distribuidos: Premissas de comprometimento bizantino e caminhos de recuperacao

Uma analise formal de engenharia sobre criptografia fintech com enfase em premissas de comprometimento bizantino e caminhos de recuperacao e restricoes operacionais adversariais.

Ler artigo relacionado

Feedback

Este artigo foi útil?

Intake Técnico

Aplique este padrão no seu ambiente com revisão de arquitetura, restrições de implementação e critérios de assurance alinhados à sua classe de sistema.

Aplicar este padrão -> Intake Técnico