Olá, estou fazendo esta entrada para propor um projeto cumulativo com o único propósito de coordenação financeira.
O DeFi amadureceu bem desde o início do Ethereum, e o conceito de financiamento programável já é uma realidade. Embora seja verdade, nem sempre foi um processo tranquilo, o efeito causal foram explorações, milhares de milhões de dólares perdidos. A solução tem sido mais auditorias e melhores ferramentas, mas sinto que o espaço está procurando a camada errada para corrigir. Chegámos a um ponto em que as auditorias e a verificação formal são padrão, mas a segurança continua a ser um jogo perpétuo de corrigir as coisas erradas. Tratamos explorações de contratos inteligentes como casos extremos ou erros do desenvolvedor, mas são os resultados previsíveis do que nosso ambiente de execução permite.
O argumento central
Ethereum é Turing completo por design. Essa generalidade é poderosa e necessária, mas será que todos os casos de uso a exigem? A resposta é não, e os sistemas financeiros são o exemplo mais claro disso.
As finanças sempre foram um conjunto de regras limitadas. Desde os primeiros empréstimos de cereais até às câmaras de compensação modernas, todos os sistemas financeiros alguma vez construídos têm sido um sistema de restrições na sua essência: um conjunto definido de participantes, activos definidos, um gatilho definido, uma fórmula definida, um horizonte temporal definido. Nada fora desses limites é permitido ou relevante. Isso nunca mudou. O que mudou foi o ambiente de execução que escolhemos para construí-los.
A maioria das vulnerabilidades do DeFi não se origina na lógica financeira. Eles se originam na computação arbitrária que os rodeia. Ao implementar um padrão declarativo em um ambiente Turing-completo, você herda toda a superfície de ataque desse ambiente sem precisar de nenhum de seu poder.
O hack DAO é o exemplo mais claro. Em 2016, 3,6 milhões de ETH foram drenados através de uma vulnerabilidade de reentrada. A causa raiz não foi um erro do desenvolvedor no sentido convencional. Foi o resultado previsível da implantação de um sistema financeiro restrito em uma camada de execução irrestrita:
function withdraw(uint256 _amount) external {
require(balances(msg.sender) >= _amount, "Insufficient balance");
(bool sent, ) = msg.sender.call{value: _amount}("");
require(sent, "Failed to send Ether");
balances(msg.sender) -= _amount; // state updated after external call
}
A função de retirada enviou ETH antes de atualizar o saldo. Como o EVM permite chamadas reentrantes, um invasor pode chamar recursivamente a retirada antes que o saldo seja diminuído. O equivalente FVL:
system: "DAO"
pool:
collect:
from:
type: anyone
what:
type: eth
rules:
conditions:
- if:
type: balance_gte
value: "1"
then:
type: enable
permission: withdraw
distribute:
formula:
type: proportional
to:
type: contributors
triggers: manual
rights:
anyone: (deposit, view)
contributors: (withdraw)
No FVL, essa classe de bug é totalmente apagada, não pela adição de uma proteção de reentrada, não pela reordenação da lógica, mas porque o ambiente de execução não permite que essa transição de estado exista em primeiro lugar.
O limite
Minha proposta traça uma linha formal.
Se um sistema financeiro pode ser descrito de ponta a ponta com transições de estado determinísticas sobre primitivas conhecidas, ele pertence ao FVL. Se exigir computação arbitrária cujos valores não podem ser conhecidos antes da execução, ele pertence ao Ethereum.
Existe uma classe pequena e legítima de protocolos, sendo Aave e Compound os principais exemplos em que a complexidade requer genuinamente computação de uso geral.
O Conjunto Primitivo
No seu nível fundamental, todo sistema financeiro é uma composição de cinco primitivos:
system: # System name
pool: # Asset collection rules
rules: # Conditional logic and distributions
rights: A combinação dessas primitivas produz:
- Conjunto de empréstimos:
pool + rights + oracles + rules - Piscina de piquetagem:
pool + time + rights - Financiamento coletivo:
pool + time + rules + rights - DAO:
pool + rights + rules + oracles + time
Um exemplo prático, um sistema de estaqueamento comunitário:
system: "CommunityStaking"
pool:
collect:
from:
type: token_holders
address: "0xYourToken"
what:
type: erc20
address: "0xStakingToken"
min:
type: value
amount: "100"
cap:
type: value
amount: "1000000"
rules:
conditions:
- if:
type: time_gt
timestamp: "1735689600"
then:
type: enable
permission: withdraw
distribute:
formula:
type: proportional
to:
type: contributors
triggers: continuous
time:
locks:
type: duration
seconds: "2592000"
vesting:
type: linear
duration: "7776000"
rights:
contributors: (stake, unstake)
admin: (pause, update_params)
oracles: ()
O modelo de execução
Todo sistema FVL é uma máquina de estados finitos. Esta é a base sobre a qual repousam as propriedades de segurança e verificabilidade do FVL.
Determinismo:
a função de transição não lê nenhum estado externo durante a execução. Dado o mesmo estado inicial e a mesma sequência ordenada de transações, quaisquer duas partes chegam ao mesmo resultado. As transições de estado são completamente limitadas e nenhuma interferência é possível no meio da execução.
Rescisão:
cada transação termina em tempo O(k), onde k é o número de condições definidas no sistema na implantação. k é corrigido na implantação e não pode ser alterado. Os custos de execução são perfeitamente previsíveis e não existe uma classe inteira de vetores de negação de serviço.
Superfície de ataque limitada:
o alfabeto de entrada é digitado e finito. Não é possível enviar uma transação que chame uma função arbitrária, faça referência a um oráculo não declarado ou acione comportamento fora do conjunto primitivo definido.
Jogabilidade:
como a função de transição é determinística e todas as entradas são registradas em um log somente anexado, o estado atual sempre pode ser reconstruído do zero. Qualquer parte com acesso ao log pode verificar de forma independente se o estado relatado está correto.
A Arquitetura
FVL é um Optimistic Rollup que se instala na rede principal Ethereum, substituindo o ambiente de execução EVM por um tempo de execução restrito especialmente desenvolvido.
┌─────────────────────────────────────────┐
│ Declaration Layer (YAML) │
│ parsing, validation, System ID │
└─────────────────┬───────────────────────┘
▼
┌─────────────────────────────────────────┐
│ Execution Layer — FVL Runtime │
│ deterministic state transitions, │
│ block production, state roots │
└─────────────────┬───────────────────────┘
▼
┌─────────────────────────────────────────┐
│ Settlement Layer — Ethereum L1 │
│ state root anchoring, data │
│ availability, fraud proof adjudication │
└─────────────────────────────────────────┘
Cada sistema implantado é identificado por um ID do sistema endereçado ao conteúdo:
system_id = Keccak256(canonical_json(system))
Qualquer alteração na definição, em qualquer campo, em qualquer condição, em qualquer permissão, produz um ID diferente. A implantação duplicada é rejeitada no nível do protocolo. Qualquer pessoa pode verificar localmente se um sistema implantado corresponde à definição esperada sem confiar no implementador.
Extensões Primitivas (FIPs)
O conjunto primitivo é intencionalmente finito. Esta é a fonte de suas garantias de segurança. Novas primitivas são adicionadas por meio de propostas de melhoria de FVL, modeladas no processo EIP da Ethereum.
O critério de aceitação é uma única pergunta: esta primitiva pode ser implementada sem a completude de Turing?
Se sim, é um candidato à inclusão. Se não, o caso de uso pertence ao Ethereum propriamente dito. Este limite é resistente. Uma versão do FVL que adiciona computação geral para acomodar casos extremos perde suas propriedades de análise estática, seu simples verificador à prova de fraude e sua garantia de execução limitada
Leitura adicional
Para uma leitura mais detalhada sobre o que é FVL e para ver uma implementação em brinquedo dele, confira abaixo
Fontesethresear
