A equipe central da Solana, Anza, colocou no ar na rede principal o Transaction V1 (SIMD-0385).
Muita gente não entendeu o que isso realmente significa.
No passado, o limite de transações unitárias da Solana $SOL era 1232 bytes. Quando desenvolvedores construíam lógicas complexas sobre isso, era como escrever código em um selo. Assim que envolvesse provas ZK para pagamentos com privacidade, multiassinaturas complexas de nível institucional com BLS, ou agregação e liquidação multi-rota em DeFi de nível avançado, o volume da transação excedia o limite em minutos.
Antes, o único jeito era dividir tudo em várias subtransações enviadas em sequência.
Mas isso traz um risco fatal: ao enviar, se alguma etapa no meio travar ou falhar, os estados antes e depois ficam desalinhados. Arbitragistas podem inserir uma “agulhada” diretamente enquanto sua primeira transação já liquidou e a segunda ainda não conectou, fazendo o usuário assumir a perda total.
Agora, essas operações criptográficas complexas e lógicas de múltiplas cadeias podem ser empacotadas na mesma transação atômica. Ou tudo passa, ou tudo volta; não há espaço no meio para ser “espetado” ou inserido alguém no meio do caminho. Além disso, elimina redundâncias do gerenciamento de múltiplas transações e reduz as interações originalmente extremamente trabalhosas para uma única ação de assinatura.
O mais interessante são as mudanças no escalonamento de recursos. Anza moveu configurações como unidades de computação (CU), taxas de prioridade e dados da conta para o cabeçalho da transação. Assim, nós RPC e validadores não precisam mais, como antes, percorrer todo o payload para só então calcular prioridade e taxa; isso pode ser feito no cabeçalho, permitindo pré-validação e alocação de recursos de forma mais direta. A eficiência de filas de negociação de alta frequência e de MEV deve melhorar no nível físico.
Apesar de o horário de lançamento ter sido adiado para o 1035º Epoch por causa de testes de integração das ferramentas do ecossistema, isso justamente mostra que o time está garantindo a base de segurança na rede principal: prefere atrasar a “competir” pelo timing de nós.
Claro, aumentar o espaço em 3 vezes não significa que as aplicações consigam aproveitar o bônus sem adaptação. O que determina até que ponto isso pode render é o progresso de adequação da infraestrutura, a pressão de carga nos nós RPC e se desenvolvedores de DApps conseguem realmente colocar ZK e lógicas institucionais em produção.
Não é um tipo de benefício explícito que dá para “puxar o preço”, mas uma vez que a base técnica aumenta a tolerância a arquiteturas complexas, o acesso a aplicações de alto valor e à entrada de capital institucional só então é verdadeiramente pavimentado.
#solana交易v1上线主网
Muita gente não entendeu o que isso realmente significa.
No passado, o limite de transações unitárias da Solana $SOL era 1232 bytes. Quando desenvolvedores construíam lógicas complexas sobre isso, era como escrever código em um selo. Assim que envolvesse provas ZK para pagamentos com privacidade, multiassinaturas complexas de nível institucional com BLS, ou agregação e liquidação multi-rota em DeFi de nível avançado, o volume da transação excedia o limite em minutos.
Antes, o único jeito era dividir tudo em várias subtransações enviadas em sequência.
Mas isso traz um risco fatal: ao enviar, se alguma etapa no meio travar ou falhar, os estados antes e depois ficam desalinhados. Arbitragistas podem inserir uma “agulhada” diretamente enquanto sua primeira transação já liquidou e a segunda ainda não conectou, fazendo o usuário assumir a perda total.
Agora, essas operações criptográficas complexas e lógicas de múltiplas cadeias podem ser empacotadas na mesma transação atômica. Ou tudo passa, ou tudo volta; não há espaço no meio para ser “espetado” ou inserido alguém no meio do caminho. Além disso, elimina redundâncias do gerenciamento de múltiplas transações e reduz as interações originalmente extremamente trabalhosas para uma única ação de assinatura.
O mais interessante são as mudanças no escalonamento de recursos. Anza moveu configurações como unidades de computação (CU), taxas de prioridade e dados da conta para o cabeçalho da transação. Assim, nós RPC e validadores não precisam mais, como antes, percorrer todo o payload para só então calcular prioridade e taxa; isso pode ser feito no cabeçalho, permitindo pré-validação e alocação de recursos de forma mais direta. A eficiência de filas de negociação de alta frequência e de MEV deve melhorar no nível físico.
Apesar de o horário de lançamento ter sido adiado para o 1035º Epoch por causa de testes de integração das ferramentas do ecossistema, isso justamente mostra que o time está garantindo a base de segurança na rede principal: prefere atrasar a “competir” pelo timing de nós.
Claro, aumentar o espaço em 3 vezes não significa que as aplicações consigam aproveitar o bônus sem adaptação. O que determina até que ponto isso pode render é o progresso de adequação da infraestrutura, a pressão de carga nos nós RPC e se desenvolvedores de DApps conseguem realmente colocar ZK e lógicas institucionais em produção.
Não é um tipo de benefício explícito que dá para “puxar o preço”, mas uma vez que a base técnica aumenta a tolerância a arquiteturas complexas, o acesso a aplicações de alto valor e à entrada de capital institucional só então é verdadeiramente pavimentado.
#solana交易v1上线主网
