Walrus właśnie stał się domyślną warstwą pamięci dla elizaOS v2, co jest dokładnie tym rodzajem ruchu „prawdziwa infrastruktura spotyka prawdziwe agenty”, którego chcę być świadkiem. elizaOS łączy @WalrusProtocol z onboardingiem (z ograniczonym czasowo kredytem), dzięki czemu nowi deweloperzy otrzymują trwałą, weryfikowalną pamięć od pierwszego dnia. Przeczytałem post o integracji i sprawdziłem podstawowe elementy: każde przesłanie prowadzi do on-chain Proof of Availability na Sui, podpisanego certyfikatu, że twój blob jest aktywny i pod opieką; to jest kotwica, która przekształca „pamięć agenta” w programowalny zasób zamiast w pamięć o najlepszym wysiłku. W przypadku wrażliwych przepływów, Seal dodaje szyfrowanie progowe + kontrolę dostępu on-chain, dzięki czemu agenci mogą dzielić się pamięcią bez rozprzestrzeniania tekstu jawnego. ❯ Dla operacji: możesz nawet śledzić ogłoszenia w kanale wiadomości Walruscan, podczas gdy podłączasz własną telemetrię. ❯ Dlaczego to ma znaczenie: roje agentów potrzebują długoterminowego, weryfikowalnego kontekstu; PoA potwierdzenia + programowalna pamięć sprawiają, że „kto widział co, kiedy” jest audytowalne w różnych przepływach pracy. ❯ Bonus: to jest niezależne od łańcucha na poziomie aplikacji, zbudowane na Solana/EVM, przechowuj pamięć na Walrus, rozliczaj dowody na Sui. Notatka dla deweloperów: wyślij mały zestaw danych za pomocą CLI, pobierz zdarzenie BlobCertified z transakcji Sui, a następnie pozwól dwóm agentom odczytać/dodać za pomocą TS SDK, jeden publiczny, jeden z ograniczeniem Seal i porównaj opóźnienia + ścieżki autoryzacji w logach. (Podziel się swoimi wynikami; zbieram dane o czasach odczytu/dodawania.) Podsumowując: stos agentów w końcu ma prymityw pamięci, który możesz weryfikować, wyceniać i komponować. Teraz zobaczmy, kto przekształci te potwierdzenia PoA w prawdziwe przepływy pracy AI.