J'ai essayé de comprendre FOGO de manière peu glamoureuse : en envoyant un transfert et en regardant ce que la chaîne exige avant de laisser quoi que ce soit bouger.
Sur une chaîne SVM, ce n'est pas poétique. Un transfert est une transaction avec un blockhash récent (donc il ne peut pas être rejoué plus tard), un signataire et un payeur de frais. Le FOGO natif est le cas propre : l'expéditeur signe, le réseau vérifie le solde et l'état change si les chiffres s'additionnent. Les propres docs de Fogo disent essentiellement : « Traitez cela comme des outils Solana — pointez votre CLI vers notre RPC mainnet et partez. »
Les tokens sont la partie que les gens interprètent mal. Vous ne « envoyez pas à un portefeuille », vous déplacez des soldes entre des comptes de token appartenant au Programme de Token. Si le destinataire n'a pas le bon compte de token associé pour ce mint, le transfert n'est pas « en attente » ou « lent » — il ne peut tout simplement pas se produire tant que ce compte n'existe pas.
Ce que l'équipe continuait à ramener, c'était les Sessions : leur façon de laisser les applications fonctionner sans que l'utilisateur paie des frais ou signe chaque clic. C'est là qu'un transfert cesse d'être purement mécanique et commence à concerner la conception des autorisations, car quelqu'un d'autre peut être le payeur de frais et le soumetteur pendant que le « oui » de l'utilisateur devient une fenêtre d'autorisation plus large.
Un ingénieur l'a dit clairement, en fixant une trace de transaction : « Si les transferts semblent invisibles, vous feriez mieux d'être obsédé par ce que l'utilisateur a réellement autorisé. »
