Binance Square
Yoshi Invest
677 Publicações

Yoshi Invest

Chia sẻ góc nhìn đầu tư Crypto, phân tích xu hướng và quản trị rủi ro. Kiên nhẫn - Kỷ luật - Lợi nhuận bền vững. Kênh thông tin không phải lời khuyên tài chính.
Detentor de BNB
Detentor de BNB
Trader Frequente
2.3 ano(s)
34 A seguir
84 Seguidores
458 Gostaram
Publicações
·
--
Verificado
Use 2 Alpha Point para fazer um booster wallet em #GRVT dias 10/7, a última tarefa é o Creatorpad receber uma alocação adicional de $GRVT no dia do TGE 21/7. Eu passei 4 horas explorando a camada de segurança (security) do @grvt_io para desmontar e descobrir: Quando “o invisível” se torna o auge da segurança. No Web3, golpes de milhões de dólares que derrubam sistemas inteiros sempre nos deixam em alerta. Por mais forte que seja, um sistema sempre carrega riscos latentes. Então como, quando o risco acontecer, fazer com que os meus ativos encontrem automaticamente um caminho de volta para a minha carteira pessoal de forma proativa? E quando o poder supremo pertence à Blockchain, não à exchange. Ao depositar dinheiro em #grvt , os ativos não ficam “no bolso” da exchange; eles são bloqueados em um smart contract transparente on-chain. A exchange só tem o poder de executar ordens por meio da assinatura do meu usuário; absolutamente não pode mover ou congelar esse valor por conta própria. Quando o risco acontecer, o usuário só precisa interagir diretamente com o smart contract abaixo para ativar o “Escape Hatch” (Porta de Saída de Emergência). Após o tempo estipulado esperando a exchange responder sem sinais, o smart contract automaticamente desbloqueia e devolve todo o dinheiro para a carteira pessoal do usuário; a exchange não consegue interferir. Funciona de forma totalmente independente e automaticamente se torna uma arma de segurança “invisível”. @grvt_io não tentou construir uma muralha realmente grossa para proteger a exchange; eles projetaram um mecanismo para: o sistema pode desabar, mas os ativos do usuário não. Ele precisa de múltiplas camadas de segurança, defesa profundamente especializada. Um sistema seguro não pode depender de uma única camada de proteção. Hybrid Exchange do futuro: desempenho + confiança + segurança dos ativos. A corrida pela infraestrutura de negociação, clara, já começou a virar para uma nova página completamente diferente. #GRVT
Use 2 Alpha Point para fazer um booster wallet em #GRVT dias 10/7, a última tarefa é o Creatorpad receber uma alocação adicional de $GRVT no dia do TGE 21/7. Eu passei 4 horas explorando a camada de segurança (security) do @grvt_io para desmontar e descobrir:
Quando “o invisível” se torna o auge da segurança.
No Web3, golpes de milhões de dólares que derrubam sistemas inteiros sempre nos deixam em alerta. Por mais forte que seja, um sistema sempre carrega riscos latentes. Então como, quando o risco acontecer, fazer com que os meus ativos encontrem automaticamente um caminho de volta para a minha carteira pessoal de forma proativa?

E quando o poder supremo pertence à Blockchain, não à exchange.
Ao depositar dinheiro em #grvt , os ativos não ficam “no bolso” da exchange; eles são bloqueados em um smart contract transparente on-chain. A exchange só tem o poder de executar ordens por meio da assinatura do meu usuário; absolutamente não pode mover ou congelar esse valor por conta própria.
Quando o risco acontecer, o usuário só precisa interagir diretamente com o smart contract abaixo para ativar o “Escape Hatch” (Porta de Saída de Emergência). Após o tempo estipulado esperando a exchange responder sem sinais, o smart contract automaticamente desbloqueia e devolve todo o dinheiro para a carteira pessoal do usuário; a exchange não consegue interferir.
Funciona de forma totalmente independente e automaticamente se torna uma arma de segurança “invisível”.
@grvt_io não tentou construir uma muralha realmente grossa para proteger a exchange; eles projetaram um mecanismo para: o sistema pode desabar, mas os ativos do usuário não.
Ele precisa de múltiplas camadas de segurança, defesa profundamente especializada.
Um sistema seguro não pode depender de uma única camada de proteção.

Hybrid Exchange do futuro: desempenho + confiança + segurança dos ativos.
A corrida pela infraestrutura de negociação, clara, já começou a virar para uma nova página completamente diferente.
#GRVT
Após a grande queda cheia de controvérsias do mercado em outubro de 2025, a confiança nas CEX volta a ser questionada. Enquanto isso, a transparência absoluta do DEX coloca grandes fundos de investimento e baleias diante de uma realidade diferente: expor carteiras, expor estratégias e perder vantagem de investimento para bots predadores de MEV. Surge então um paradoxo irônico: para ser seguro, é preciso ser transparente; mas transparência demais vira um “suicídio” estratégico. Isso me lembra a frase clássica de Ronald Reagan: “Trust, but verify” (Confie, mas verifique). Então, em que lugar a confiança deve ser depositada para que o sistema possa tanto ser verificável quanto proteger os direitos de privacidade estratégica? Esse é exatamente o ponto de contato em que @grvt_io aparece. Em vez de obrigar os usuários a escolher entre privacidade estratégica e capacidade de verificação, #grvt mantém o order flow em off-chain para reduzir ao máximo o risco de expor estratégias de grandes fundos e baleias. Em contrapartida, todos os resultados de execução das ordens precisam vir acompanhados por uma prova criptográfica que é enviada para on-chain, permitindo que a rede verifique que o estado final é válido. Isso ajuda a reduzir ao mínimo o “caixa-preta” que antes os usuários eram forçados a confiar ao operador. O que o ZK-Proof muda não é a confiança, mas sim o quanto ainda é necessário confiar. GRVT não elimina a confiança. GRVT apenas reduz o escopo da confiança. Talvez no futuro, a disputa entre exchanges deixe de ser a pergunta “quem é mais confiável?”, e passe a ser “quem consegue projetar um melhor modelo de confiança?”. Se a confiança não pode desaparecer, então o que importa mais não é definir o lugar correto para ela existir? @grvt_io #grvt
Após a grande queda cheia de controvérsias do mercado em outubro de 2025, a confiança nas CEX volta a ser questionada.

Enquanto isso, a transparência absoluta do DEX coloca grandes fundos de investimento e baleias diante de uma realidade diferente: expor carteiras, expor estratégias e perder vantagem de investimento para bots predadores de MEV.

Surge então um paradoxo irônico: para ser seguro, é preciso ser transparente; mas transparência demais vira um “suicídio” estratégico.

Isso me lembra a frase clássica de Ronald Reagan: “Trust, but verify” (Confie, mas verifique).

Então, em que lugar a confiança deve ser depositada para que o sistema possa tanto ser verificável quanto proteger os direitos de privacidade estratégica?

Esse é exatamente o ponto de contato em que @grvt_io aparece.

Em vez de obrigar os usuários a escolher entre privacidade estratégica e capacidade de verificação, #grvt mantém o order flow em off-chain para reduzir ao máximo o risco de expor estratégias de grandes fundos e baleias.

Em contrapartida, todos os resultados de execução das ordens precisam vir acompanhados por uma prova criptográfica que é enviada para on-chain, permitindo que a rede verifique que o estado final é válido. Isso ajuda a reduzir ao mínimo o “caixa-preta” que antes os usuários eram forçados a confiar ao operador.

O que o ZK-Proof muda não é a confiança, mas sim o quanto ainda é necessário confiar.

GRVT não elimina a confiança. GRVT apenas reduz o escopo da confiança.

Talvez no futuro, a disputa entre exchanges deixe de ser a pergunta “quem é mais confiável?”, e passe a ser “quem consegue projetar um melhor modelo de confiança?”.

Se a confiança não pode desaparecer, então o que importa mais não é definir o lugar correto para ela existir? @grvt_io #grvt
A correspondência (matching) de fato precisa de Blockchain? Grande parte de nós já passou por uma fase no Web3 na qual a regra era: quanto mais coisas levadas para o on-chain, melhor, e quanto mais a blockchain fizer, melhor. À primeira vista, isso parece totalmente razoável. Mas o sistema é obrigado a sacrificar a velocidade de correspondência (matching) e até criar uma grande pressão na rede blockchain apenas por causa de milhões de ordens de compra/venda colocadas e canceladas a cada segundo por traders. Talvez o problema nunca tenha sido colocar mais coisas na blockchain, e sim o que realmente PRECISA de blockchain. Se matching e settlement têm responsabilidades completamente diferentes, por que eles precisariam rodar na mesma arquitetura? O que chamou minha atenção no <c-1/> @grvt_io é que eles não tentaram construir um sistema “tudo-em-um”. Eles separaram o matching para processar off-chain, porque a função dele é apenas corresponder ordens o mais rápido possível; o que precisa ser otimizado é desempenho e baixa latência. Enquanto isso, o settlement é mantido on-chain para cumprir seu papel de transferência de ativos e registrar o estado final de forma imutável. Cada componente se concentra apenas na sua responsabilidade central. Matching não precisa de blockchain; settlement é que precisa. O que #grvt separou não é um produto; é responsabilidade do sistema. Por isso, o Hybrid Exchange não é simplesmente uma palavra-chave de marketing que combina CEX e DEX. Ele define um novo tipo de infraestrutura de negociação: a propriedade dos ativos pertence à blockchain, enquanto o desempenho operacional pertence ao sistema refinado off-chain. $LAB $DEXE
A correspondência (matching) de fato precisa de Blockchain?
Grande parte de nós já passou por uma fase no Web3 na qual a regra era: quanto mais coisas levadas para o on-chain, melhor, e quanto mais a blockchain fizer, melhor.

À primeira vista, isso parece totalmente razoável. Mas o sistema é obrigado a sacrificar a velocidade de correspondência (matching) e até criar uma grande pressão na rede blockchain apenas por causa de milhões de ordens de compra/venda colocadas e canceladas a cada segundo por traders.

Talvez o problema nunca tenha sido colocar mais coisas na blockchain, e sim o que realmente PRECISA de blockchain. Se matching e settlement têm responsabilidades completamente diferentes, por que eles precisariam rodar na mesma arquitetura?

O que chamou minha atenção no <c-1/> @grvt_io é que eles não tentaram construir um sistema “tudo-em-um”. Eles separaram o matching para processar off-chain, porque a função dele é apenas corresponder ordens o mais rápido possível; o que precisa ser otimizado é desempenho e baixa latência. Enquanto isso, o settlement é mantido on-chain para cumprir seu papel de transferência de ativos e registrar o estado final de forma imutável.

Cada componente se concentra apenas na sua responsabilidade central. Matching não precisa de blockchain; settlement é que precisa.
O que #grvt separou não é um produto; é responsabilidade do sistema.

Por isso, o Hybrid Exchange não é simplesmente uma palavra-chave de marketing que combina CEX e DEX. Ele define um novo tipo de infraestrutura de negociação: a propriedade dos ativos pertence à blockchain, enquanto o desempenho operacional pertence ao sistema refinado off-chain.
$LAB $DEXE
Trocar 15 minutos por 1 transação para “liberdade financeira”: será que vale a pena? A experiência “all-in-one” da CEX me fez esquecer que eu estava transferindo ativos para um terceiro. Só quando migrei para uma carteira pessoal, a diferença ficou clara: fazer algumas ações com poucos cliques na CEX agora vira 15 minutos de preocupação, tentando pensar no próximo passo. Mesmo assim, no fim, eu ainda voltei para a CEX. Todo mundo no cripto já ouviu a frase: “Not your keys, not your coins.” Sabemos que a auto custódia é mais segura. Mas se for assim, por que a CEX continua sendo a escolha da maioria dos usuários? Os usuários não recusam a auto custódia. Eles apenas recusam uma experiência que os faz ficar pensando nela o tempo todo. Eles não querem auto custódia. Eles querem esquecer que existe custódia. Isso também foi o que me chamou atenção ao ler os docs da GRVT. Em vez de encarar a auto custódia como um problema que o usuário precisa aprender a se adaptar, eles veem a experiência da auto custódia como o problema que precisa ser redesenhado. Ao aplicar Account Abstraction (AA) e um modelo de Hybrid Exchange, a GRVT permite que você crie uma carteira usando a própria conta do Google ou do Apple, para que você execute trades de forma fluida como na CEX, sem precisar ficar assinando/aprovando (approve) cada ordem continuamente. Seus ativos continuam sendo seus, mas a experiência é idêntica à da Web2. A GRVT não começa pelo problema da custódia. A GRVT começa pelo problema de UX da auto custódia. Talvez a próxima etapa da competição do Web3 não esteja em quem oferece a melhor auto custódia, mas em quem faz com que a auto custódia se torne uma parte natural da experiência. Quando a auto custódia ficar “invisível”, que motivos o usuário ainda teria para continuar escolhendo uma CEX? @grvt_io #grvt $TAC $LAB
Trocar 15 minutos por 1 transação para “liberdade financeira”: será que vale a pena?

A experiência “all-in-one” da CEX me fez esquecer que eu estava transferindo ativos para um terceiro. Só quando migrei para uma carteira pessoal, a diferença ficou clara: fazer algumas ações com poucos cliques na CEX agora vira 15 minutos de preocupação, tentando pensar no próximo passo.

Mesmo assim, no fim, eu ainda voltei para a CEX.
Todo mundo no cripto já ouviu a frase: “Not your keys, not your coins.” Sabemos que a auto custódia é mais segura.
Mas se for assim, por que a CEX continua sendo a escolha da maioria dos usuários?

Os usuários não recusam a auto custódia. Eles apenas recusam uma experiência que os faz ficar pensando nela o tempo todo.
Eles não querem auto custódia.
Eles querem esquecer que existe custódia.

Isso também foi o que me chamou atenção ao ler os docs da GRVT. Em vez de encarar a auto custódia como um problema que o usuário precisa aprender a se adaptar, eles veem a experiência da auto custódia como o problema que precisa ser redesenhado.
Ao aplicar Account Abstraction (AA) e um modelo de Hybrid Exchange, a GRVT permite que você crie uma carteira usando a própria conta do Google ou do Apple, para que você execute trades de forma fluida como na CEX, sem precisar ficar assinando/aprovando (approve) cada ordem continuamente. Seus ativos continuam sendo seus, mas a experiência é idêntica à da Web2.
A GRVT não começa pelo problema da custódia.
A GRVT começa pelo problema de UX da auto custódia.

Talvez a próxima etapa da competição do Web3 não esteja em quem oferece a melhor auto custódia, mas em quem faz com que a auto custódia se torne uma parte natural da experiência.

Quando a auto custódia ficar “invisível”, que motivos o usuário ainda teria para continuar escolhendo uma CEX?
@grvt_io #grvt $TAC $LAB
Certo dia, eu só queria lidar com uma transação relativamente simples. Retirar fundos de uma CEX para uma carteira, fazer bridge, aprovar, fazer swap e então seguir para outro protocolo. Tudo funcionou exatamente como foi projetado. Mas, só depois de terminar o que eu tinha que fazer, eu percebi que o que mais me deixou exausto não foram as taxas de transação, e sim o fato de ter que ficar convertendo continuamente entre muitos sistemas apenas para concluir um único objetivo. Isso me fez levantar uma pergunta: o problema do cripto está em cada produto individual, ou está na forma como esses produtos estão sendo combinados? Por isso eu prestei atenção ao GRVT e dediquei quase duas horas para ler os docs do projeto com cuidado. No começo eu pensei que se tratava apenas de uma Hybrid Exchange. Mas quanto mais eu lia, mais eu percebia que a documentação do GRVT não gira em torno de apenas um recurso; ela também aborda vários aspectos como a experiência do usuário, segurança, controle sobre os ativos e a arquitetura de transações. As abordagens do GRVT realmente se sustentam na prática, ou apenas parecem plausíveis no papel? @grvt_io #grvt $TAC $LAB
Certo dia, eu só queria lidar com uma transação relativamente simples.

Retirar fundos de uma CEX para uma carteira, fazer bridge, aprovar, fazer swap e então seguir para outro protocolo.

Tudo funcionou exatamente como foi projetado. Mas, só depois de terminar o que eu tinha que fazer, eu percebi que o que mais me deixou exausto não foram as taxas de transação, e sim o fato de ter que ficar convertendo continuamente entre muitos sistemas apenas para concluir um único objetivo.

Isso me fez levantar uma pergunta: o problema do cripto está em cada produto individual, ou está na forma como esses produtos estão sendo combinados?

Por isso eu prestei atenção ao GRVT e dediquei quase duas horas para ler os docs do projeto com cuidado.

No começo eu pensei que se tratava apenas de uma Hybrid Exchange. Mas quanto mais eu lia, mais eu percebia que a documentação do GRVT não gira em torno de apenas um recurso; ela também aborda vários aspectos como a experiência do usuário, segurança, controle sobre os ativos e a arquitetura de transações.

As abordagens do GRVT realmente se sustentam na prática, ou apenas parecem plausíveis no papel?
@grvt_io #grvt $TAC $LAB
VELOCIDADE E A VERDADE DA IA ON-CHAIN? Eu mesmo já construí um sistema de gerenciamento de portfólio DeFi automatizado: a IA analisa off-chain e depois envia comandos para o Smart Contract via API Web2. No começo, rodava muito rápido, mas quando o fluxo de capital do mundo real começou a operar, eu fiquei inquieto: como ter certeza de que o servidor intermediário executa corretamente o modelo? E se o resultado for alterado antes de chegar à blockchain? Para resolver isso, tentei forçar o sistema a rodar com ZKML para que a IA pudesse provar a correção por meio de matemática. O resultado foi um desastre de performance: a velocidade de processamento caiu 1000 vezes. O comando de transação, que antes era em milissegundos, virou fila. O sistema on-chain fica seguro, mas “lento como uma tartaruga”. Eu continuei com a Arquitetura de IA Híbrida (HACA) de @OpenGradient para separar o processo de inferência (inference) da verificação (verification) em dois cronogramas. Todas as requisições são encaminhadas diretamente para os Nós de GPU, e o resultado é devolvido imediatamente com baixa latência, como no Web2, sem precisar esperar o tempo de criação do bloco on-chain. Depois, o novo Nó gera uma prova criptográfica e a submete à cadeia para que os Full Nodes de auditoria verifiquem. Tratamento completo dos riscos provenientes da defasagem de tempo entre receber o resultado e concluir a verificação. Esse mecanismo elimina a latência de criação de blocos, reduz a pressão e otimiza a experiência. No entanto, ainda é necessário que o sistema dependa da integridade do hardware da GPU. A IA on-chain conquista os usuários pela instantaneidade e pela transparência. Meu feedback para #OPG é: $OPG não deve apenas provar a velocidade de um dApp como no Web2 e a segurança como no Web3, mas também precisa provar adicionalmente a integridade do hardware da GPU. Se a IA do futuro deixar de confiar na promessa e passar a verificar por meio de matemática, então a corrida da IA deixa de ser “velocidade ou segurança” e passa a ser “velocidade para alcançar confiança”.
VELOCIDADE E A VERDADE DA IA ON-CHAIN?
Eu mesmo já construí um sistema de gerenciamento de portfólio DeFi automatizado: a IA analisa off-chain e depois envia comandos para o Smart Contract via API Web2. No começo, rodava muito rápido, mas quando o fluxo de capital do mundo real começou a operar, eu fiquei inquieto: como ter certeza de que o servidor intermediário executa corretamente o modelo? E se o resultado for alterado antes de chegar à blockchain?
Para resolver isso, tentei forçar o sistema a rodar com ZKML para que a IA pudesse provar a correção por meio de matemática. O resultado foi um desastre de performance: a velocidade de processamento caiu 1000 vezes. O comando de transação, que antes era em milissegundos, virou fila. O sistema on-chain fica seguro, mas “lento como uma tartaruga”.

Eu continuei com a Arquitetura de IA Híbrida (HACA) de @OpenGradient para separar o processo de inferência (inference) da verificação (verification) em dois cronogramas.
Todas as requisições são encaminhadas diretamente para os Nós de GPU, e o resultado é devolvido imediatamente com baixa latência, como no Web2, sem precisar esperar o tempo de criação do bloco on-chain. Depois, o novo Nó gera uma prova criptográfica e a submete à cadeia para que os Full Nodes de auditoria verifiquem.
Tratamento completo dos riscos provenientes da defasagem de tempo entre receber o resultado e concluir a verificação.
Esse mecanismo elimina a latência de criação de blocos, reduz a pressão e otimiza a experiência.
No entanto, ainda é necessário que o sistema dependa da integridade do hardware da GPU.

A IA on-chain conquista os usuários pela instantaneidade e pela transparência. Meu feedback para #OPG é: $OPG não deve apenas provar a velocidade de um dApp como no Web2 e a segurança como no Web3, mas também precisa provar adicionalmente a integridade do hardware da GPU.

Se a IA do futuro deixar de confiar na promessa e passar a verificar por meio de matemática, então a corrida da IA deixa de ser “velocidade ou segurança” e passa a ser “velocidade para alcançar confiança”.
Ontem à 1h, eu troquei 0,7 ETH por meio de 3 Wallets, paguei uma Taxa de Gas de 18,4 USD, comi 2,7% de Slippage e ainda cliquei no Approval errado mais uma vez... Ficando ali, assistindo a Route girar pela Bridge e pelo Aggregator, parecia meio engraçado. Às vezes, o cripto não perde por causa do mercado. Perde porque a stack que usamos é complicada demais! Honestamente, eu costumava achar que toda nova chain, nova VM, nova arquitetura era bom. Soava premium. Soava como o futuro. Mas quando você realmente constrói, percebe que a coisa mais cara não é a Taxa de Gas, nem a Taxa de Funding e nem mesmo uma ordem de PnL a -46,8 USD. A coisa mais cara é forçar os usuários a mudarem os hábitos. Um dApp que faz as pessoas moverem liquidez, reaprenderem o fluxo da Wallet, entenderem Bridge de novo, esperarem a Finality de novo... como isso é diferente de fazer clientes trocarem de cafeteria só porque o copo parece mais bonito? O mercado não se importa com coisas que são “tecnicamente corretas”, mas comportamentalmente erradas. É por isso que comecei a prestar atenção em @OpenGradient não porque a palavra AI pareça brilhante. Mas porque a forma como ela enquadra o problema é um pouco diferente: manter compatibilidade EVM, Solidity, Liquidez em tempo real e então inserir inference de AI como uma camada nativa de EVM via Precompile. Parece pouco. Position Data — Cross-chain Price Spread — Market Sentiment → Saída de AI verificável com prova TEE, para que o Smart Contract consiga processar Conditional Logic sozinho. Não precisa derrubar a casa e reconstruí-la. Não precisa arrastar os usuários numa peregrinação para uma nova chain. A Base tem Liquidez, a Arbitrum tem Assets, a Optimism tem Comportamento do Usuário; se chamadas de AI multi-chain puderem reunir essas peças no mesmo fluxo de decisão, então o roteamento de DeFi com AI finalmente tem base real para rodar. Eu não acredito mais na frase “boa tecnologia vai vencer sozinha”. Boa tecnologia que faz o mercado pagar fricção demais ainda é só um slide bonito! Então qual caminho vocês escolhem: reconstruir tudo do zero e limpo, ou fazer com que o que já existe fique mais inteligente? #OPG $OPG @OpenGradient $VELVET $LAB
Ontem à 1h, eu troquei 0,7 ETH por meio de 3 Wallets, paguei uma Taxa de Gas de 18,4 USD, comi 2,7% de Slippage e ainda cliquei no Approval errado mais uma vez...

Ficando ali, assistindo a Route girar pela Bridge e pelo Aggregator, parecia meio engraçado.

Às vezes, o cripto não perde por causa do mercado.

Perde porque a stack que usamos é complicada demais!

Honestamente, eu costumava achar que toda nova chain, nova VM, nova arquitetura era bom.

Soava premium.

Soava como o futuro.

Mas quando você realmente constrói, percebe que a coisa mais cara não é a Taxa de Gas, nem a Taxa de Funding e nem mesmo uma ordem de PnL a -46,8 USD.

A coisa mais cara é forçar os usuários a mudarem os hábitos.

Um dApp que faz as pessoas moverem liquidez, reaprenderem o fluxo da Wallet, entenderem Bridge de novo, esperarem a Finality de novo... como isso é diferente de fazer clientes trocarem de cafeteria só porque o copo parece mais bonito?

O mercado não se importa com coisas que são “tecnicamente corretas”, mas comportamentalmente erradas.

É por isso que comecei a prestar atenção em @OpenGradient não porque a palavra AI pareça brilhante.

Mas porque a forma como ela enquadra o problema é um pouco diferente: manter compatibilidade EVM, Solidity, Liquidez em tempo real e então inserir inference de AI como uma camada nativa de EVM via Precompile.

Parece pouco.

Position Data — Cross-chain Price Spread — Market Sentiment → Saída de AI verificável com prova TEE, para que o Smart Contract consiga processar Conditional Logic sozinho.

Não precisa derrubar a casa e reconstruí-la.

Não precisa arrastar os usuários numa peregrinação para uma nova chain.

A Base tem Liquidez, a Arbitrum tem Assets, a Optimism tem Comportamento do Usuário; se chamadas de AI multi-chain puderem reunir essas peças no mesmo fluxo de decisão, então o roteamento de DeFi com AI finalmente tem base real para rodar.

Eu não acredito mais na frase “boa tecnologia vai vencer sozinha”.

Boa tecnologia que faz o mercado pagar fricção demais ainda é só um slide bonito!

Então qual caminho vocês escolhem: reconstruir tudo do zero e limpo, ou fazer com que o que já existe fique mais inteligente?
#OPG $OPG @OpenGradient $VELVET $LAB
Achei algo bastante interessante: Toda vez que um token é listado em uma grande bolsa. Toda vez que um airdrop ou incentivo começa, muita gente passa a prestar atenção. Mas depois que os eventos terminam, eles quase desaparecem do mercado. Então o que faz um token de infraestrutura de IA existir para que eles continuem por perto, sem desaparecer? A maior parte dos tokens de infraestrutura de IA hoje foca em atrair usuários. @OpenGradient construiu o Model Hub, onde todas as solicitações de IA são pagas com OPG. Na minha opinião, é aí que o token deixa de ser um ativo meramente especulativo e se torna parte de cada uso de IA. Para fazer isso, #OPG integrou a camada de pagamento x402 diretamente em todas as solicitações de IA. Separar incentive de adoption. Um lado vem do benefício econômico; o outro vem da necessidade real de uso. Se o incentivo é uma chuva, então adoption é o lugar onde a água fica armazenada. Incentive traz os usuários. Adoption mantém eles por perto. O valor econômico do token $OPG é sustentável porque se baseia em uso real. Não em atenção. Se o AI protocol quiser criar valor econômico sustentável, ele precisa provar sua capacidade de transformar atração em retenção. Talvez isso seja tanto um ponto forte quanto um ponto fraco do OPG. Se houver sugestões, acho que #OPG não deveria apenas provar que x402 funciona. A OPG precisa provar que cada vez mais solicitações de IA são insubstituíveis sem aquela camada de pagamento. Só quando o uso cresce de forma natural, o token consegue passar de valor esperado para valor gerado a partir da demanda real. Se qualquer AI protocol consegue atrair atenção, então o que se torna uma verdadeira vantagem competitiva para manter os usuários por perto?
Achei algo bastante interessante:
Toda vez que um token é listado em uma grande bolsa.
Toda vez que um airdrop ou incentivo começa, muita gente passa a prestar atenção.
Mas depois que os eventos terminam, eles quase desaparecem do mercado.
Então o que faz um token de infraestrutura de IA existir para que eles continuem por perto, sem desaparecer?

A maior parte dos tokens de infraestrutura de IA hoje foca em atrair usuários.

@OpenGradient construiu o Model Hub, onde todas as solicitações de IA são pagas com OPG. Na minha opinião, é aí que o token deixa de ser um ativo meramente especulativo e se torna parte de cada uso de IA.

Para fazer isso, #OPG integrou a camada de pagamento x402 diretamente em todas as solicitações de IA.

Separar incentive de adoption. Um lado vem do benefício econômico; o outro vem da necessidade real de uso.

Se o incentivo é uma chuva, então adoption é o lugar onde a água fica armazenada.
Incentive traz os usuários.
Adoption mantém eles por perto.

O valor econômico do token $OPG é sustentável porque se baseia em uso real.
Não em atenção.

Se o AI protocol quiser criar valor econômico sustentável, ele precisa provar sua capacidade de transformar atração em retenção.

Talvez isso seja tanto um ponto forte quanto um ponto fraco do OPG.
Se houver sugestões, acho que #OPG não deveria apenas provar que x402 funciona. A OPG precisa provar que cada vez mais solicitações de IA são insubstituíveis sem aquela camada de pagamento. Só quando o uso cresce de forma natural, o token consegue passar de valor esperado para valor gerado a partir da demanda real.

Se qualquer AI protocol consegue atrair atenção, então o que se torna uma verdadeira vantagem competitiva para manter os usuários por perto?
Nosso painel mostra que a latência diminuiu. Mas o número de tentativas de reenvio (retry) aumentou. O estranho é que o sistema parece mais rápido, mas a experiência real está menos estável. Uma das investigações me levou a um node @OpenGradient , que o sistema escolheu por ser o mais próximo em termos geográficos — então enviar um lote de inferências para ele era uma escolha bastante natural. As três primeiras requests ultrapassaram o limite de retry quase imediatamente. Primeiro eu culpei o timeout. Depois, a fila. Cheguei até a suspeitar de um novo lançamento de modelo. Mas um node mais distante ainda processava a mesma carga de trabalho sem nenhum problema. Foi então que percebi que eu estava otimizando o métrico errado. A distância indica apenas onde a request começa. Ela não reflete todo o percurso que a request precisa completar. O tráfego de rede passa por uma rota movimentada antes de chegar ao node. A inferência ainda começa rápido, mas as confirmações de verificação (verification) voltam de forma irregular. A aplicação enxerga que a inferência foi concluída, enquanto o sinal de confiança ainda chega atrasado — e então faz um retry automático de um trabalho que, na verdade, não tinha falhado. O problema não está em o node ser perto ou longe. Está no fato de que o métrico que eu usei para otimizar só mede parte do request. Todo sistema, no fim, se torna aquilo que o seu métrico está otimizando. Voltando no tempo, eu não escolhi o node errado. Eu escolhi o ponto errado para encerrar a medição. Eu considero a request concluída quando a inferência termina, enquanto, para #OPG , a experiência só é realmente concluída depois da verification. Se a request só termina após a verification, então o métrico também deve ser encerrado ali. Se a inferência termina antes de a confiança estar concluída, então o que devemos otimizar de fato? $OPG $CAP
Nosso painel mostra que a latência diminuiu. Mas o número de tentativas de reenvio (retry) aumentou.

O estranho é que o sistema parece mais rápido, mas a experiência real está menos estável.

Uma das investigações me levou a um node @OpenGradient , que o sistema escolheu por ser o mais próximo em termos geográficos — então enviar um lote de inferências para ele era uma escolha bastante natural.

As três primeiras requests ultrapassaram o limite de retry quase imediatamente.

Primeiro eu culpei o timeout. Depois, a fila. Cheguei até a suspeitar de um novo lançamento de modelo. Mas um node mais distante ainda processava a mesma carga de trabalho sem nenhum problema.

Foi então que percebi que eu estava otimizando o métrico errado.

A distância indica apenas onde a request começa. Ela não reflete todo o percurso que a request precisa completar.

O tráfego de rede passa por uma rota movimentada antes de chegar ao node. A inferência ainda começa rápido, mas as confirmações de verificação (verification) voltam de forma irregular. A aplicação enxerga que a inferência foi concluída, enquanto o sinal de confiança ainda chega atrasado — e então faz um retry automático de um trabalho que, na verdade, não tinha falhado.

O problema não está em o node ser perto ou longe.

Está no fato de que o métrico que eu usei para otimizar só mede parte do request.

Todo sistema, no fim, se torna aquilo que o seu métrico está otimizando.

Voltando no tempo, eu não escolhi o node errado.
Eu escolhi o ponto errado para encerrar a medição.
Eu considero a request concluída quando a inferência termina, enquanto, para #OPG , a experiência só é realmente concluída depois da verification.

Se a request só termina após a verification, então o métrico também deve ser encerrado ali.

Se a inferência termina antes de a confiança estar concluída, então o que devemos otimizar de fato?
$OPG $CAP
Quando transfiro alguns milhões de đồng, eu só preciso confirmar com o rosto. Mas quando assino um contrato para comprar um apartamento, eu estou disposto a dedicar mais tempo para verificar cada cláusula. O interessante é que eu nunca escolhi a forma mais rigorosa de verificação para tudo. Porque cada nível de confiança tem um custo. Tempo. Conveniência. Custo. Isso me fez pensar em IA. Se a IA vai atender a milhões de tarefas diferentes, será que todas as tarefas realmente precisam do mesmo nível de confiança? @OpenGradient encara o problema por outro ângulo. Em vez de existir apenas um modo de verificação, #OPG criou vários níveis de verificação diferentes. Verificação básica (Vanilla) para casos que exigem velocidade. Ambiente de Execução Confiável (TEE) para aplicações que precisam equilibrar desempenho e confiabilidade. ZKML para casos em que se requer o mais alto nível de garantia criptográfica. Em vez de aplicar o mesmo padrão a todas as situações, cada aplicação pode escolher o nível de verificação adequado às suas necessidades. Talvez o futuro da IA não seja criar mais confiança. Mas sim criar o nível certo de confiança necessário. $OPG $DEXE $LAB
Quando transfiro alguns milhões de đồng, eu só preciso confirmar com o rosto.

Mas quando assino um contrato para comprar um apartamento, eu estou disposto a dedicar mais tempo para verificar cada cláusula.

O interessante é que eu nunca escolhi a forma mais rigorosa de verificação para tudo.

Porque cada nível de confiança tem um custo.

Tempo.

Conveniência.

Custo.

Isso me fez pensar em IA.

Se a IA vai atender a milhões de tarefas diferentes, será que todas as tarefas realmente precisam do mesmo nível de confiança?

@OpenGradient encara o problema por outro ângulo.

Em vez de existir apenas um modo de verificação, #OPG criou vários níveis de verificação diferentes.

Verificação básica (Vanilla) para casos que exigem velocidade.

Ambiente de Execução Confiável (TEE) para aplicações que precisam equilibrar desempenho e confiabilidade.

ZKML para casos em que se requer o mais alto nível de garantia criptográfica.

Em vez de aplicar o mesmo padrão a todas as situações, cada aplicação pode escolher o nível de verificação adequado às suas necessidades.

Talvez o futuro da IA não seja criar mais confiança.

Mas sim criar o nível certo de confiança necessário.
$OPG $DEXE $LAB
Um relatório com dados errados. Um e-mail foi enviado com o conteúdo errado. O chefe não pergunta: “Onde está o erro?” Mas pergunta: “Quem fez?” Isso me fez pensar em um problema ainda maior. A IA está se desenvolvendo cada vez mais, e a IA se tornou uma necessidade indispensável na vida humana. Então, você já se perguntou: Se a IA errar, quem será responsabilizado? E, dentro de @OpenGradient , essa pergunta é vista por um ângulo bem interessante. Em vez de apenas se concentrar em gerar resultados. #OPG está construindo uma Trust Layer, em que cada decisão pode ser rastreada, em vez de simplesmente deixar um resultado sem ninguém saber como ele foi criado. Quando uma decisão pode ser rastreada, a responsabilidade também pode ser rastreada. Uma IA não se torna confiável porque comete menos erros. Ela se torna confiável quando a responsabilidade é projetada desde o início, em vez de ter que buscá-la depois de cada falha. Talvez o futuro da IA não seja uma IA mais inteligente. Mas uma IA mais confiável. $OPG $DEXE $SLX
Um relatório com dados errados.
Um e-mail foi enviado com o conteúdo errado.
O chefe não pergunta:
“Onde está o erro?”
Mas pergunta:
“Quem fez?”
Isso me fez pensar em um problema ainda maior.
A IA está se desenvolvendo cada vez mais, e a IA se tornou uma necessidade indispensável na vida humana.
Então, você já se perguntou:
Se a IA errar, quem será responsabilizado?

E, dentro de @OpenGradient , essa pergunta é vista por um ângulo bem interessante.

Em vez de apenas se concentrar em gerar resultados.

#OPG está construindo uma Trust Layer, em que cada decisão pode ser rastreada, em vez de simplesmente deixar um resultado sem ninguém saber como ele foi criado.

Quando uma decisão pode ser rastreada, a responsabilidade também pode ser rastreada.

Uma IA não se torna confiável porque comete menos erros.

Ela se torna confiável quando a responsabilidade é projetada desde o início, em vez de ter que buscá-la depois de cada falha.

Talvez o futuro da IA não seja uma IA mais inteligente.

Mas uma IA mais confiável.
$OPG $DEXE $SLX
10% para indivíduos. 15% para interações. A lista detalhada e os planos, experiências e lições acumuladas ao longo dos anos. Eu compartilho tudo com a IA. No começo, eram apenas conversas. Mas, com o tempo, a IA começou a memorizar. O que a IA lembra não é dado aleatório. É a forma como eu trabalho. Como eu tomo decisões. As coisas que aprendi ao longo dos anos. O interessante é que se amanhã eu mudar para um modelo diferente, o que eu não quero perder não é o modelo. Mas tudo o que foi memorizado. E em @OpenGradient isso fica muito claro. MemSync não foi apenas construído para ajudar a IA a lembrar. Foi construído sobre uma suposição maior: A memória pode existir como uma camada separada. E quando a memória se torna uma infraestrutura, a pergunta importante pode não ser mais: "A IA consegue lembrar de quanto?" Mas sim: "Quem possui a memória da IA?" Talvez o que for mais valioso na IA do futuro não seja a capacidade de lembrar. Mas o direito de propriedade sobre o que foi memorizado. #OPG $OPG $DEXE $LAB
10% para indivíduos.
15% para interações.
A lista detalhada e os planos, experiências e lições acumuladas ao longo dos anos. Eu compartilho tudo com a IA.

No começo, eram apenas conversas.

Mas, com o tempo, a IA começou a memorizar.

O que a IA lembra não é dado aleatório.
É a forma como eu trabalho.
Como eu tomo decisões.
As coisas que aprendi ao longo dos anos.

O interessante é que se amanhã eu mudar para um modelo diferente, o que eu não quero perder não é o modelo.
Mas tudo o que foi memorizado.

E em @OpenGradient isso fica muito claro.

MemSync não foi apenas construído para ajudar a IA a lembrar.

Foi construído sobre uma suposição maior:

A memória pode existir como uma camada separada.

E quando a memória se torna uma infraestrutura, a pergunta importante pode não ser mais:

"A IA consegue lembrar de quanto?"
Mas sim:
"Quem possui a memória da IA?"

Talvez o que for mais valioso na IA do futuro não seja a capacidade de lembrar.

Mas o direito de propriedade sobre o que foi memorizado.
#OPG $OPG $DEXE $LAB
POR QUE QUANDO ALGUÉM ABRE UM FORMULÁRIO DE INSCRIÇÃO, ELE NÃO PREENCHER IMEDIATAMENTE? Eles vão direto para o final. Procuram uma linha muito pequena: "Aprovado em até 24–48 horas" ou "Nós iremos revisar sua aplicação" E só de ver isso. Eles param. Não fazem mais perguntas. Não tentam começar. Não é porque não querem participar. Mas porque naquele momento, a ação de "participar" não é mais entendida como um primeiro passo. Ela é transformada em algo que precisa ser aceito antes de ser considerado existente. Uma pessoa não está realmente livre para participar se precisar esperar que alguém a permita começar. E é aí que @OpenGradient se diferencia. A maioria das IA hoje em dia, o direito de participação é decidido por um grupo de pessoas com poder de aprovação. #OPG está construindo um futuro onde a inovação não é limitada pela autorização prévia. Um futuro onde a Contribuição Aberta se torna o padrão. E a Participação não precisa ser aprovada antes. Onde o direito de participar não é decidido pela aprovação prévia. Começa com a escolha de uma pessoa em participar. Talvez a pergunta mais importante não seja: "Quantas pessoas querem construir isso?" Mas sim: "Quantas pessoas têm permissão para construir isso?" O futuro da IA pode não ser decidido pelos ecossistemas com mais interesse. Mas sim pelos ecossistemas com mais pessoas que podem participar. $OPG $DEXE
POR QUE QUANDO ALGUÉM ABRE UM FORMULÁRIO DE INSCRIÇÃO, ELE NÃO PREENCHER IMEDIATAMENTE?
Eles vão direto para o final.
Procuram uma linha muito pequena:
"Aprovado em até 24–48 horas"
ou
"Nós iremos revisar sua aplicação"
E só de ver isso.
Eles param.
Não fazem mais perguntas.
Não tentam começar.
Não é porque não querem participar.
Mas porque naquele momento, a ação de "participar" não é mais entendida como um primeiro passo.
Ela é transformada em algo que precisa ser aceito antes de ser considerado existente.

Uma pessoa não está realmente livre para participar se precisar esperar que alguém a permita começar.

E é aí que @OpenGradient se diferencia.
A maioria das IA hoje em dia, o direito de participação é decidido por um grupo de pessoas com poder de aprovação.

#OPG está construindo um futuro onde a inovação não é limitada pela autorização prévia.

Um futuro onde a Contribuição Aberta se torna o padrão.
E a Participação não precisa ser aprovada antes.

Onde o direito de participar não é decidido pela aprovação prévia.
Começa com a escolha de uma pessoa em participar.

Talvez a pergunta mais importante não seja:
"Quantas pessoas querem construir isso?"
Mas sim:
"Quantas pessoas têm permissão para construir isso?"

O futuro da IA pode não ser decidido pelos ecossistemas com mais interesse.
Mas sim pelos ecossistemas com mais pessoas que podem participar. $OPG $DEXE
Duas pessoas podem ter a mesma cozinha. Com os mesmos ingredientes. Com as mesmas ferramentas. Mas uma pessoa está sempre criando novos pratos. Enquanto a outra apenas repete os pratos familiares. Por que um conjunto idêntico de recursos, mas combinações diferentes, resulta em resultados diferentes? Quando se busca uma grande evolução, a maioria das pessoas começa procurando algo novo. Uma nova ferramenta. Uma nova ideia. Um novo recurso. Isso é uma forma de Cegueira à Recombinação. Estamos tão focados em encontrar novos componentes que perdemos de vista os novos valores que estão nos componentes já existentes. Inovações frequentemente não surgem de um novo componente. Mas sim de como os componentes antigos são reconfigurados. A IA enfrenta um desafio semelhante. Talvez isso explique @OpenGradient . Enquanto a maioria dos sistemas de IA foca em adicionar mais capacidades, #OPG está construindo uma infraestrutura para que as capacidades existentes possam gerar valor além de si mesmas. Um futuro assim requer: ✓ Interoperabilidade ✓ Componentes Especializados ✓ Infraestrutura Modular ✓ Coordenação Aberta Um sistema não se torna mais valioso apenas porque tem mais capacidades. Mas porque pode gerar algo novo a partir das capacidades que já possui. O futuro da IA pode não pertencer aos modelos maiores. Mas às ecossistemas que conseguem recombinar mais rapidamente. Talvez a pergunta mais importante não seja: “Quais capacidades ainda nos faltam?” Mas sim: “Já aproveitamos ao máximo as capacidades que temos?” #OPG $OPG @OpenGradient
Duas pessoas podem ter a mesma cozinha.

Com os mesmos ingredientes.

Com as mesmas ferramentas.

Mas uma pessoa está sempre criando novos pratos.

Enquanto a outra apenas repete os pratos familiares.

Por que um conjunto idêntico de recursos, mas combinações diferentes, resulta em resultados diferentes?

Quando se busca uma grande evolução, a maioria das pessoas começa procurando algo novo.

Uma nova ferramenta.

Uma nova ideia.

Um novo recurso.

Isso é uma forma de Cegueira à Recombinação.

Estamos tão focados em encontrar novos componentes que perdemos de vista os novos valores que estão nos componentes já existentes.

Inovações frequentemente não surgem de um novo componente.

Mas sim de como os componentes antigos são reconfigurados.

A IA enfrenta um desafio semelhante.
Talvez isso explique @OpenGradient .

Enquanto a maioria dos sistemas de IA foca em adicionar mais capacidades,
#OPG está construindo uma infraestrutura para que as capacidades existentes possam gerar valor além de si mesmas.

Um futuro assim requer:

✓ Interoperabilidade

✓ Componentes Especializados

✓ Infraestrutura Modular

✓ Coordenação Aberta

Um sistema não se torna mais valioso apenas porque tem mais capacidades.

Mas porque pode gerar algo novo a partir das capacidades que já possui.

O futuro da IA pode não pertencer aos modelos maiores.

Mas às ecossistemas que conseguem recombinar mais rapidamente.

Talvez a pergunta mais importante não seja:

“Quais capacidades ainda nos faltam?”

Mas sim:

“Já aproveitamos ao máximo as capacidades que temos?” #OPG $OPG @OpenGradient
Outro dia eu pedi comida pelo app. O prato que recebi era bem diferente da foto. O que mais me incomodou não foi a comida. Mas sim o fato de eu achar que não tinha como reclamar. Alguns minutos depois, percebi que ainda tinha um botão de feedback. De repente, a sensação de desconforto diminuiu bastante. Embora naquele momento tudo ainda não estivesse resolvido. Pensando bem, é algo bem curioso. O que faz uma decisão ser mais facilmente aceita? As pessoas aceitam menos decisões que não podem ser questionadas. Quanto mais uma decisão impacta as pessoas, mais ela precisa ser questionada. Mas as decisões que mais impactam geralmente são as mais difíceis de serem questionadas. Eu chamo isso de Escudo de Desafio. Uma barreira invisível que faz com que as decisões mais necessárias de serem questionadas se tornem as mais difíceis de serem contestadas. Um sistema é mais confiável quando suas decisões podem ser desafiadas. Mas se não sabemos se uma decisão realmente pode ser desafiada ou não. Então, também não sabemos se esse sistema é realmente mais confiável. É aí que vejo que @OpenGradient está indo em uma direção bem interessante. Permite que as decisões sejam revisadas, debatidas e reavaliadas. E se isso for verdade. O futuro da IA pode não ser definido pelos sistemas mais confiáveis. Mas sim pelos sistemas que permitem que suas decisões sejam mais desafiadas. #OPG $OPG
Outro dia eu pedi comida pelo app.

O prato que recebi era bem diferente da foto.

O que mais me incomodou não foi a comida.

Mas sim o fato de eu achar que não tinha como reclamar.

Alguns minutos depois, percebi que ainda tinha um botão de feedback.

De repente, a sensação de desconforto diminuiu bastante.

Embora naquele momento tudo ainda não estivesse resolvido.

Pensando bem, é algo bem curioso.

O que faz uma decisão ser mais facilmente aceita?

As pessoas aceitam menos decisões que não podem ser questionadas.

Quanto mais uma decisão impacta as pessoas, mais ela precisa ser questionada.

Mas as decisões que mais impactam geralmente são as mais difíceis de serem questionadas.

Eu chamo isso de Escudo de Desafio.

Uma barreira invisível que faz com que as decisões mais necessárias de serem questionadas se tornem as mais difíceis de serem contestadas.

Um sistema é mais confiável quando suas decisões podem ser desafiadas.

Mas se não sabemos se uma decisão realmente pode ser desafiada ou não.

Então, também não sabemos se esse sistema é realmente mais confiável.

É aí que vejo que @OpenGradient está indo em uma direção bem interessante.

Permite que as decisões sejam revisadas, debatidas e reavaliadas.

E se isso for verdade.

O futuro da IA pode não ser definido pelos sistemas mais confiáveis.

Mas sim pelos sistemas que permitem que suas decisões sejam mais desafiadas.
#OPG $OPG
Recentemente, eu percebi uma coisa bem estranha. As coisas que têm mais sucesso geralmente são as que são mais difíceis de mudar. Quanto melhor um sistema funciona. Menos pessoas querem mudá-lo. No início, isso parece fazer sentido. Mas o que acontece quando o mundo continua mudando enquanto o sistema não? Muitos sistemas não desaparecem por falhas. Eles desaparecem porque tiveram sucesso por tempo demais. Eu chamo isso de "Evolution Trap". Uma armadilha que surge quando o sucesso atual corrói a capacidade de evolução no futuro. Talvez porque os sistemas que existem há mais tempo não sejam os sistemas mais perfeitos. Mas sim aqueles que podem evoluir. Mas o que faz um sistema ser capaz de evoluir? Um sistema é difícil de adaptar se cada nova mudança exige que ele seja reconstruído do zero. Cada mudança se torna uma reestruturação. E com o tempo. Manter tudo igual se torna mais fácil que mudar. Esse também é o problema @OpenGradient que está sendo resolvido. Ao invés de forçar o ecossistema de IA a ser reestruturado sempre que uma nova habilidade aparece. #OPG permite que o ecossistema de IA melhore continuamente sem precisar reconstruir tudo. Novos componentes podem surgir sem fazer com que os componentes existentes deixem de cooperar entre si. Quando mudar não significa mais reestruturar. Evoluir não é mais um sacrifício. Isso se torna um processo contínuo. E se isso for verdade. O futuro da IA pode não ser definido pelos modelos mais poderosos. Mas pelos ecossistemas que têm a capacidade de evoluir mais rapidamente. #OPG $OPG
Recentemente, eu percebi uma coisa bem estranha.

As coisas que têm mais sucesso geralmente são as que são mais difíceis de mudar.
Quanto melhor um sistema funciona.
Menos pessoas querem mudá-lo.

No início, isso parece fazer sentido.

Mas o que acontece quando o mundo continua mudando enquanto o sistema não?

Muitos sistemas não desaparecem por falhas.
Eles desaparecem porque tiveram sucesso por tempo demais.
Eu chamo isso de "Evolution Trap".
Uma armadilha que surge quando o sucesso atual corrói a capacidade de evolução no futuro.

Talvez porque os sistemas que existem há mais tempo não sejam os sistemas mais perfeitos.

Mas sim aqueles que podem evoluir.

Mas o que faz um sistema ser capaz de evoluir?

Um sistema é difícil de adaptar se cada nova mudança exige que ele seja reconstruído do zero.
Cada mudança se torna uma reestruturação.

E com o tempo.
Manter tudo igual se torna mais fácil que mudar.

Esse também é o problema @OpenGradient que está sendo resolvido.
Ao invés de forçar o ecossistema de IA a ser reestruturado sempre que uma nova habilidade aparece.

#OPG permite que o ecossistema de IA melhore continuamente sem precisar reconstruir tudo.

Novos componentes podem surgir sem fazer com que os componentes existentes deixem de cooperar entre si.

Quando mudar não significa mais reestruturar.
Evoluir não é mais um sacrifício.
Isso se torna um processo contínuo.

E se isso for verdade.
O futuro da IA pode não ser definido pelos modelos mais poderosos.

Mas pelos ecossistemas que têm a capacidade de evoluir mais rapidamente. #OPG $OPG
Ultimamente, tenho uma vibe meio preguiçosa. Sempre que preciso encontrar algo, raramente fico rolando para baixo para ver toda a lista. Geralmente, só olho as primeiras sugestões e já decido na hora. Parece que estou escolhendo. Mas, pensando bem, a maior parte do trabalho já foi feito antes. Alguém já decidiu o que aparece na minha frente. Nesse momento, me lembrei de @OpenGradient que está fazendo algo bem interessante: transformar a IA de algo que precisa ser confiável em algo que pode ser verificado. Parece que isso é uma questão sobre IA. Mas vejo um ângulo mais intrigante. Se um dia tivermos milhares ou milhões de IAs coexistindo, o maior problema pode não ser qual IA é a melhor. E sim, qual IA é a que está sendo usada. Nesse caso, os usuários não vão avaliar cada IA individualmente. Eles vão depender de uma camada de sistema para decidir qual IA aparece na sua frente, qual IA é chamada e qual IA é deixada de lado. Aqui é onde vejo a questão de Acesso se tornando interessante. A verificação nos ajuda a saber se uma IA está agindo corretamente. Mas quem verifica o sistema que está escolhendo as IAs por nós? Se essa camada de acesso não puder ser verificada, estamos apenas mudando a confiança de uma IA para um novo gatekeeper. Talvez, quando a IA se tornar algo comum, a IA mais poderosa não seja a que tem mais poder. A coisa mais poderosa pode ser o sistema que decide qual IA tem permissão para aparecer. Então, se eu tivesse uma sugestão para @OpenGradient , eu diria: não se limite a verificar a IA. Procure uma maneira de verificar quem escolhe a IA. Porque se a IA precisa ser verificada, então quem escolhe a IA provavelmente precisa ser verificado ainda mais. #OPG $OPG
Ultimamente, tenho uma vibe meio preguiçosa.

Sempre que preciso encontrar algo, raramente fico rolando para baixo para ver toda a lista. Geralmente, só olho as primeiras sugestões e já decido na hora. Parece que estou escolhendo. Mas, pensando bem, a maior parte do trabalho já foi feito antes. Alguém já decidiu o que aparece na minha frente.

Nesse momento, me lembrei de @OpenGradient que está fazendo algo bem interessante: transformar a IA de algo que precisa ser confiável em algo que pode ser verificado.

Parece que isso é uma questão sobre IA. Mas vejo um ângulo mais intrigante.

Se um dia tivermos milhares ou milhões de IAs coexistindo, o maior problema pode não ser qual IA é a melhor.

E sim, qual IA é a que está sendo usada.

Nesse caso, os usuários não vão avaliar cada IA individualmente. Eles vão depender de uma camada de sistema para decidir qual IA aparece na sua frente, qual IA é chamada e qual IA é deixada de lado.

Aqui é onde vejo a questão de Acesso se tornando interessante.

A verificação nos ajuda a saber se uma IA está agindo corretamente. Mas quem verifica o sistema que está escolhendo as IAs por nós?

Se essa camada de acesso não puder ser verificada, estamos apenas mudando a confiança de uma IA para um novo gatekeeper.

Talvez, quando a IA se tornar algo comum, a IA mais poderosa não seja a que tem mais poder.

A coisa mais poderosa pode ser o sistema que decide qual IA tem permissão para aparecer.

Então, se eu tivesse uma sugestão para @OpenGradient , eu diria: não se limite a verificar a IA.

Procure uma maneira de verificar quem escolhe a IA.

Porque se a IA precisa ser verificada, então quem escolhe a IA provavelmente precisa ser verificado ainda mais. #OPG $OPG
Hoje de manhã, tomei um café com um brother que tem um restaurante. Ele reclamou que quando abriu o restaurante, fazia tudo sozinho e ainda conseguia se virar. Ia ao mercado, cozinhava, atendia os clientes, fazia a conta. Mas quando o movimento aumentou, não deu mais. No começo, ele achou que precisava ser mais rápido. Agora, ele pensa diferente. Para o restaurante crescer ainda mais, precisa dividir as tarefas. Aí, de repente, eu pensei na OpenGradient. Tem uma coisa meio estranha. Um restaurante cresce dividindo o trabalho. Mas a IA hoje está crescendo juntando mais trabalho em um único sistema. Então, se a IA realmente se tornar uma infraestrutura, ela vai se parecer mais com um restaurante ou com o que estamos construindo hoje? À medida que o sistema avança, as funções começam a se separar em papéis distintos. @OpenGradient está olhando nessa direção. O Compute gera resultados. A Verification confirma se esses resultados são confiáveis ou não. Quando esses dois papéis são agrupados em um só lugar, o sistema só tem um jeito de criar confiança: confiar em si mesmo. Quando eles são separados, a geração de resultados e a verificação dos resultados se tornam duas camadas independentes. Isso geralmente é um sinal de que uma infraestrutura está se formando. Talvez a Infraestrutura de IA também seja assim. Ela aparece quando Compute e Verification estão separados. Mas o que mais me intriga está por trás disso. Se essa regra estiver certa, Compute e Verification podem ser apenas o primeiro passo. Talvez em alguns anos não vejamos a IA como um modelo. Mas como um ecossistema de papéis diferentes. Cada papel existe porque faz bem uma única coisa. Ou talvez não. Mas se eu tivesse que fazer uma aposta, apostaria em sistemas onde a confiança não precisa mais se validar sozinha.#OPG $OPG
Hoje de manhã, tomei um café com um brother que tem um restaurante.

Ele reclamou que quando abriu o restaurante, fazia tudo sozinho e ainda conseguia se virar. Ia ao mercado, cozinhava, atendia os clientes, fazia a conta.

Mas quando o movimento aumentou, não deu mais.

No começo, ele achou que precisava ser mais rápido.

Agora, ele pensa diferente.

Para o restaurante crescer ainda mais, precisa dividir as tarefas.

Aí, de repente, eu pensei na OpenGradient.

Tem uma coisa meio estranha.

Um restaurante cresce dividindo o trabalho.

Mas a IA hoje está crescendo juntando mais trabalho em um único sistema.

Então, se a IA realmente se tornar uma infraestrutura, ela vai se parecer mais com um restaurante ou com o que estamos construindo hoje?

À medida que o sistema avança, as funções começam a se separar em papéis distintos.

@OpenGradient está olhando nessa direção.

O Compute gera resultados.

A Verification confirma se esses resultados são confiáveis ou não.

Quando esses dois papéis são agrupados em um só lugar, o sistema só tem um jeito de criar confiança: confiar em si mesmo.

Quando eles são separados, a geração de resultados e a verificação dos resultados se tornam duas camadas independentes.

Isso geralmente é um sinal de que uma infraestrutura está se formando.

Talvez a Infraestrutura de IA também seja assim.

Ela aparece quando Compute e Verification estão separados.

Mas o que mais me intriga está por trás disso.

Se essa regra estiver certa, Compute e Verification podem ser apenas o primeiro passo.

Talvez em alguns anos não vejamos a IA como um modelo.

Mas como um ecossistema de papéis diferentes.

Cada papel existe porque faz bem uma única coisa.

Ou talvez não.

Mas se eu tivesse que fazer uma aposta, apostaria em sistemas onde a confiança não precisa mais se validar sozinha.#OPG $OPG
Acabei de enviar o relatório para o chefe. Parece que fiz mais rápido do que das outras vezes, então estou meio feliz. Um tempo depois, o chefe me chamou, pensei que ia receber um elogio. Mas, na verdade, fui chamado de atenção porque os dados estavam todos errados. Depois que desliguei, percebi: aquele relatório eu fiz com o ChatGPT e não revisei nada. O que me parou não foi o relatório estar errado. Mas sim o fato de eu ter confiado tanto em uma resposta que pulei a etapa de verificação. Quando o ChatGPT foi lançado, isso era bem raro. Eu checava quase tudo porque ele errava bastante. Mas agora a IA está muito melhor. E talvez essa seja a mudança mais surpreendente. Não é que a IA esteja mais inteligente. É que a IA se tornou mais familiar. Ninguém verifica coisas em que eles já confiam. É aí que comecei a ver outro problema. O que acontece quando a IA é boa o suficiente para que as pessoas comecem a confiar nela? Talvez essa seja uma pergunta muito mais interessante do que o quanto a IA vai ficar mais inteligente. E é também onde @OpenGradient começa a se tornar relevante. Uma IA que acerta 99% das vezes faz com que o 1% restante seja mais importante do que nunca. A capacidade de gerar respostas. A verificação decide quando devemos confiar nessa resposta. O paradoxo é: Quanto mais poderosa a IA. Menos as pessoas verificam. Quando menos se verifica, a verificação se torna ainda mais necessária. Se o futuro da IA é ser utilizada em todos os lugares, a próxima corrida pode não ser mais sobre criar mais inteligência. Mas sim sobre ajudar os usuários a saber quando confiar nessa inteligência. Talvez essa seja a razão pela qual as camadas de verificação estão se tornando mais importantes. E é aí que a OpenGradient está focando desde cedo. Quanto mais poderosa a IA. A pergunta "está certo?" se tornará mais importante do que nunca. #OPG $OPG
Acabei de enviar o relatório para o chefe.
Parece que fiz mais rápido do que das outras vezes, então estou meio feliz.
Um tempo depois, o chefe me chamou, pensei que ia receber um elogio.
Mas, na verdade, fui chamado de atenção porque os dados estavam todos errados.
Depois que desliguei, percebi: aquele relatório eu fiz com o ChatGPT e não revisei nada.

O que me parou não foi o relatório estar errado.
Mas sim o fato de eu ter confiado tanto em uma resposta que pulei a etapa de verificação.

Quando o ChatGPT foi lançado, isso era bem raro.
Eu checava quase tudo porque ele errava bastante.
Mas agora a IA está muito melhor.

E talvez essa seja a mudança mais surpreendente.

Não é que a IA esteja mais inteligente.
É que a IA se tornou mais familiar.
Ninguém verifica coisas em que eles já confiam.

É aí que comecei a ver outro problema.
O que acontece quando a IA é boa o suficiente para que as pessoas comecem a confiar nela?

Talvez essa seja uma pergunta muito mais interessante do que o quanto a IA vai ficar mais inteligente.
E é também onde @OpenGradient começa a se tornar relevante.

Uma IA que acerta 99% das vezes faz com que o 1% restante seja mais importante do que nunca.
A capacidade de gerar respostas.
A verificação decide quando devemos confiar nessa resposta.

O paradoxo é:
Quanto mais poderosa a IA.
Menos as pessoas verificam.
Quando menos se verifica, a verificação se torna ainda mais necessária.

Se o futuro da IA é ser utilizada em todos os lugares, a próxima corrida pode não ser mais sobre criar mais inteligência.

Mas sim sobre ajudar os usuários a saber quando confiar nessa inteligência.

Talvez essa seja a razão pela qual as camadas de verificação estão se tornando mais importantes.

E é aí que a OpenGradient está focando desde cedo.
Quanto mais poderosa a IA.
A pergunta "está certo?" se tornará mais importante do que nunca. #OPG $OPG
Na tecnologia, o erro mais caro geralmente não é resolver o problema errado. Mas sim resolver muito bem um problema que não é mais o gargalo. A IA pode estar caindo nessa armadilha. A maior parte da corrida atualmente gira em torno de uma suposição: quanto mais inteligente o modelo, maior o valor gerado. Portanto, a indústria continua despejando mais compute, dados e capital em inteligência. Mas o que acontece se a inteligência não for mais o maior gargalo? Muitos problemas importantes da IA surgem depois que a resposta já foi gerada: Como saber qual modelo foi executado? Como garantir que o resultado não foi alterado? Como verificar em vez de apenas confiar? Isso não é mais um problema de inteligência. É um problema de confiança. A OpenGradient foi construída com base nessa distinção. A HACA vê execução e verificação como duas camadas diferentes. Se essas duas camadas forem realmente independentes, um modelo mais robusto não criará automaticamente maior confiança. É uma troca notável. Otimizar a inteligência ajuda a IA a gerar respostas melhores. Mas não resolve o problema de saber se essas respostas podem ser verificadas ou não. Uma indústria pode continuar investindo onde antes era o maior gargalo. Mas quando o gargalo muda, os custos aumentarão mais rápido do que o valor gerado. A IA pode não faltar em modelos mais inteligentes. Ela pode estar faltando em sistemas que nos ajudem a saber quando devemos confiar neles. @OpenGradient #OPG $OPG
Na tecnologia, o erro mais caro geralmente não é resolver o problema errado.

Mas sim resolver muito bem um problema que não é mais o gargalo.

A IA pode estar caindo nessa armadilha.

A maior parte da corrida atualmente gira em torno de uma suposição: quanto mais inteligente o modelo, maior o valor gerado. Portanto, a indústria continua despejando mais compute, dados e capital em inteligência.

Mas o que acontece se a inteligência não for mais o maior gargalo?

Muitos problemas importantes da IA surgem depois que a resposta já foi gerada:

Como saber qual modelo foi executado?

Como garantir que o resultado não foi alterado?

Como verificar em vez de apenas confiar?

Isso não é mais um problema de inteligência.

É um problema de confiança.

A OpenGradient foi construída com base nessa distinção. A HACA vê execução e verificação como duas camadas diferentes.

Se essas duas camadas forem realmente independentes, um modelo mais robusto não criará automaticamente maior confiança.

É uma troca notável.

Otimizar a inteligência ajuda a IA a gerar respostas melhores.

Mas não resolve o problema de saber se essas respostas podem ser verificadas ou não.

Uma indústria pode continuar investindo onde antes era o maior gargalo.

Mas quando o gargalo muda, os custos aumentarão mais rápido do que o valor gerado.

A IA pode não faltar em modelos mais inteligentes.

Ela pode estar faltando em sistemas que nos ajudem a saber quando devemos confiar neles.
@OpenGradient #OPG $OPG
Inicia sessão para explorar mais conteúdos
Junta-te a utilizadores de criptomoedas de todo o mundo na Binance Square
⚡️ Obtém informações úteis e recentes sobre criptomoedas.
💬 Com a confiança da maior exchange de criptomoedas do mundo.
👍 Descobre perspetivas reais de criadores verificados.
E-mail/Número de telefone
Mapa do sítio
Preferências de cookies
Termos e Condições da Plataforma