Ethereum's Next Stop Glamsterdam: The Core Upgrades You Must Know

Foresight NewsPubblicato 2026-06-23Pubblicato ultima volta 2026-06-23

Introduzione

The Glamsterdam upgrade, scheduled for late 2026, is a major Ethereum hard fork combining the Amsterdam execution layer and Glasgow consensus layer updates. Its primary goal is not simply increasing throughput but restructuring Ethereum's block production, validation, and resource pricing to enable future scaling. Key technical changes include **EIP-7732 (ePBS)**, which formally enshrines proposer-builder separation into the protocol. This decouples consensus and execution tasks, extending the execution payload propagation window to ~9 seconds. This provides more time for node verification, allowing for safer increases in block capacity (Gas limit) in the future. Another core component is **EIP-7928 (Block-Level Access Lists - BAL)**. It mandates a list of all state accessed within a block, moving this feature from an optional transaction-level (EIP-2930) to a mandatory block-level requirement. This explicit access list enables client optimizations like parallel disk reads and state root computations, paving the way for parallel execution. To manage long-term state growth, **EIP-8037** increases the cost of creating new state (e.g., accounts, storage slots), separating the pricing of permanent database bloat from temporary computation. This allows execution capacity to scale more aggressively without causing state size to explode proportionally. The planned upgrade bundle includes around 10 EIPs categorized into: 1) Core protocol restructuring (ePBS, BAL), 2) Resource pri...


Author: KarenZ, Foresight News


The Glamsterdam upgrade for Ethereum is most easily misunderstood as yet another purely technical iteration to increase throughput. A more accurate description is: it is reorganizing Ethereum's block proposal process, validation process, resource pricing methods, and more, laying the groundwork for higher gas limits, larger blob capacities, and future parallel execution.


As of June 23, 2026, ethereum.org labels Glamsterdam as an upgrade planned for the second half of 2026. The name Glamsterdam comes from the combination of the execution layer upgrade "Amsterdam" and the consensus layer upgrade "Gloas." The official roadmap places it after Fusaka in December 2025 and before Hegotá, clearly listing two main features: enshrined proposer-builder separation (ePBS) and block-level access lists (BAL).


Who Proposes, Who Builds: ePBS Codifies Block Creation Roles into the Protocol


Today's Ethereum block production is like a very tight shift change: someone is responsible for proposing a block, someone else for building the transaction content, with dependencies on off-protocol infrastructure like MEV-Boost and third-party relays.


This system has been running for years, but it places some trust relationships off-protocol and also forces validators to handle consensus, execution, data availability, and other tasks within a very short time window.


One of Glamsterdam's headline changes, EIP-7732, or ePBS (Enshrined Proposer-Builder Separation), codifies the division of labor between proposers and builders into the protocol.


Simply put, the proposer is responsible for selecting the consensus block, and the builder is responsible for preparing the transaction content inside it. A builder cannot just make verbal promises; it must first "post a bond" within the protocol: specify exactly which execution payload it will deliver and how much it is willing to pay the proposer. Subsequently, a Payload Timeliness Committee (PTC) will check whether it delivers on time.


The key to this change is not just reducing reliance on third-party relays but also buying time for block propagation and validation.


Today, validators need to handle both consensus and execution simultaneously within a very short critical window; ePBS separates these two tasks, allowing the execution payload to be revealed and verified later. According to the design of EIP-7732, the propagation window for the execution payload—the available time for data to spread through the network and be received by nodes—can be extended from about 2 seconds to about 9 seconds. With a longer window, Ethereum can more safely handle larger payloads when increasing block capacity, reducing the risk of missed votes or reorgs due to nodes not having enough time to download, verify, and vote.


This change may not be directly perceptible to ordinary users, but it is crucial for Ethereum scaling. A longer propagation and validation window means the network can more securely handle larger loads. CoinDesk reported on June 16, 2026, citing Ethereum Foundation DevOps engineer Parithosh Jayanthi, that Glamsterdam could be one of the biggest forks since the Merge, changing many assumptions about Ethereum and preparing for larger-scale scaling in the future.


BAL and Repricing: Scaling Isn't Just About Stepping on the Gas, It's Also About Managing the Database


Another core change in Glamsterdam is EIP-7928, Block-Level Access Lists.


It can be understood as providing each block with an "access record": which accounts and which storage locations were touched during the block's execution, and what the related state became after execution, are all recorded. This way, nodes no longer process blocks completely like opening a blind box; they can know earlier which data needs to be read and which computations can be advanced in parallel.


The earlier EIP-2930 introduced transaction-level access lists, but they were optional and saw limited practical use. The change with EIP-7928 is that it elevates access lists to the block level: the block header contains a "fingerprint" (hash) of this list, while the execution payload stores the complete list. Nodes executing the block will verify whether the access records written in the list actually match the block's execution process; if they don't match, the block is invalid.


Why is this important? Today, when Ethereum executes transactions, many data accesses are only known when that specific step is reached. Nodes don't know if a batch of transactions will read/write the same account or storage slot simultaneously, making it hard to confidently process them in parallel. BAL explicitly writes out the access trajectory during block execution, allowing clients to perform parallel disk reads, parallel transaction validation, parallel state root computation, and also update the state in some scenarios without fully replaying transactions. It's not a direct button to lower user fees but opens up engineering space for client-side parallelization.


But Glamsterdam's scaling logic isn't just about "widening the road." It also needs to manage the long-term bloat of Ethereum's database. EIP-8037 increases state creation costs and introduces a cost per state byte (CPSB). State can be understood as the database content that Ethereum must preserve long-term, such as new accounts, new contracts, and new storage slots. Transactions end after execution, but state remains in the ledger that all nodes must maintain; if state grows too fast, running a node becomes increasingly expensive, and decentralization is gradually eroded.


The background numbers provided by EIP-8037 are straightforward: As of January 2026, a Geth node database dedicated to state is about 390 GiB; after the mainnet gas limit increased from 30 million to 60 million, daily new state growth rose from about 105 MiB to about 326 MiB, translating to an annual growth of about 116 GiB. Extrapolating proportionally under a 200 million gas limit, state growth could reach about 387 GiB per year and exceed the 650 GiB performance degradation threshold in less than a year.


Therefore, what EIP-8037 aims to do is separate the pricing of "temporary computation" from "permanently occupying the database." Creating new state will be more expensive because it imposes not a one-time computation cost on the network but a long-term storage burden.


Vitalik Buterin also mentioned, while explaining the Glamsterdam scaling roadmap, that Glamsterdam will separate state creation costs from execution and calldata costs: the goal is to allow execution capacity to expand more significantly while preventing state size from膨胀 at the same rate.


Looking at them together, BAL makes it easier for nodes to process blocks in parallel, addressing "running faster"; state creation repricing makes operations that long-term occupy the database pay a higher cost, addressing "don't let the ledger get fatter and fatter." Glamsterdam's scaling isn't simply raising the gas limit; it's asking a more realistic question: can Ethereum accommodate more transactions while preventing block propagation, transaction validation, and state storage pressures from spiraling out of control.


The Glamsterdam EIP List Takes Shape: Which Are Set, Which Are Still Waiting?


As of June 23, 2026, according to tracking content on Forkcast regarding Ethereum upgrades, Ethereum developers are currently testing the Glamsterdam upgrade in devnets environments, with deployment scheduled for Sepolia on August 3 and for the mainnet on September 16 (specific deployment dates are subject to change).




Currently, 10 EIPs are planned for inclusion in the Glamsterdam list:


  • EIP-7708 (ETH transfers will also trigger logs, facilitating indexing and tracking of native ETH transfers)
  • EIP-7732 (ePBS, codifying proposer-builder separation into the protocol, reducing reliance on off-protocol relays)
  • EIP-7778 (Removes block gas accounting related to gas refunds, simplifying block gas calculation)
  • EIP-7843 (Adds SLOTNUM opcode, allowing contracts to read the current slot number)
  • EIP-7928 (Block-level access lists BAL, recording accounts and storage locations accessed during block execution, paving the way for parallel verification)
  • EIP-7954 (Increases the maximum contract size limit, allowing larger contract bytecode)
  • EIP-7976 (Increases calldata floor cost, adjusting the minimum cost for calldata)
  • EIP-7981 (Increases access list cost, recalibrating gas pricing for access lists)
  • EIP-8024 (Backward-compatible SWAPN, DUPN, EXCHANGE opcodes, enhancing EVM stack operation capabilities)
  • EIP-8037 (Increases state creation gas cost,抑制 state database过快膨胀)


These EIPs can be roughly categorized into several groups: The first is the restructuring of block proposal and validation processes, with EIP-7732 and EIP-7928 at the core; the second is resource pricing adjustments, including EIP-7778, EIP-7976, EIP-7981, and EIP-8037; the third is EVM and developer experience changes, including EIP-7708, EIP-7843, EIP-7954, and EIP-8024.


In other words, Glamsterdam isn't changing just one feature point; it's simultaneously upgrading block creation roles, parallel validation, gas pricing, and EVM usability.


Another batch of EIPs remains on the "Considered for Inclusion" list:


  • EIP-2780 (Splits transaction intrinsic gas by resource)
  • EIP-7610 (Contract creation reverts when using a non-empty storage account)
  • EIP-7688 (Future-compatible consensus layer data structure)
  • EIP-7904 (Computational gas cost analysis, potentially to be removed from Glamsterdam)
  • EIP-7975 (eth/70, partial block receipt lists)
  • EIP-7997 (Deterministic factory contracts)
  • EIP-8038 (State access gas cost updates)
  • EIP-8045 (Excludes slashed validators from continuing to propose blocks)
  • EIP-8061 (Increases exit and merge churn)
  • EIP-8070 (eth/72, Sparse Blobpool)
  • EIP-8080 (Allows exits to use the consolidation queue)
  • EIP-8136 (Cell-level deltas for data column broadcasts)
  • EIP-8159 (eth/71, block access list exchange)
  • EIP-8246 (Removes SELFDESTRUCT burn)
  • EIP-8282 (Builder Execution Requests, provides dedicated registration and exit requests for ePBS builders)


Additionally, Forkcast currently lists EIP-8254 (Limits the number of deposit requests per execution layer block to 8192) on the "Proposed for Inclusion" list.


From a staker's perspective, EIP-8061 and EIP-8080 on the considered list are particularly noteworthy. For stakers, this could mean improved exit liquidity. Figment stated in an article on May 5, 2026, that institutional stakers should pay most attention to ePBS, EIP-8061, and EIP-8080, estimating that under the ~38.9 million ETH staked规模 as of April 2026, EIP-8061 could increase the exit churn limit from 256 ETH/epoch to ~1187 ETH/epoch, while EIP-8080 allows regular exits to utilize spare capacity in the merge queue. Figment also cautions that all pre-mainnet numbers should be considered speculative.


Source: Figment


The Protocol is Upgrading, and Foundation Members Are Also Changing


The technical preparation for Glamsterdam coincides almost simultaneously with personnel changes in the Ethereum Foundation's Protocol cluster. An Ethereum Foundation blog post on May 11, 2026, stated that Glamsterdam had reached several milestones: a 200 million gas limit floor had been established as a credible post-Glamsterdam target, ePBS was running stably on multi-client Glamsterdam devnets, and EIP-8037 was finalized.


The same article announced a leadership transition for the Protocol cluster: Will Corcoran, Kev Wedderburn, and Fredrik would become the new Protocol cluster coordinators. Original coordinators Barnabé Monnot and Tim Beiko left the Ethereum Foundation, and Alex Stokes is on leave.


The Foundation's description of the分工 for the three new coordinators is: Will Corcoran has cross-team coordination experience; Kev Wedderburn leads the zkEVM team; Fredrik leads the Protocol Security and Trillion Dollar Security project.


These changes didn't stop at the protocol team. On June 18, 2026, Hsiao-Wei Wang posted that after a leave of absence, they had decided to resign from their positions as Co-Executive Director and Board Member of the Ethereum Foundation.


Former Ethereum Foundation researcher Dankrad Feist stated on June 19, 2026, that those leaving the EF are believers in CROPS (Censorship & Capture Resistance, Open Source, Privacy, Security), that the issue isn't with strategy but with management, and called this wave of talent outflow slightly bearish for Ethereum. Miden co-founder Azeem interpreted it from the opposite direction, believing the EF struggles to change itself, and that the talent outflow might lead to the formation of new organizations better able to execute the Ethereum roadmap, ultimately a net positive for the ecosystem long-term.


The narrative from within the Ethereum Foundation sounds more like setting boundaries. Ethereum Foundation Interim Co-Executive Director Bastian Aue (Aerugo) responded that reasons for EF members leaving include strategic disagreements, role fit, normal institutional turnover, or personal choice, that the EF wouldn't discuss individual personnel matters on social media, but stated that those leaving should have a dignified way to depart.


The Ethereum Foundation later provided a clearer organizational narrative via an official Twitter thread: realizing Ethereum's potential requires a coalition of multiple organizations, and over the past year, several organizations have jointly enhanced the ecosystem's resilience and capabilities. Examples listed by the EF include: ethlabs announced on June 23 (a non-profit R&D lab focused on the next stage of Ethereum and ETH adoption), the Eth Apps Guild launched in April 2026 (focused on real adoption of Ethereum-native apps, especially in emerging markets), the Ethereum Economic Zone launched in 2026 (aiming to reduce ecosystem fragmentation through synchronous composability and zero-knowledge real-time proofs), and Argot established in 2025 (an autonomous collective of engineers and researchers maintaining Solidity and open-source compiler tools).


This official thread makes the recent changes at the Ethereum Foundation easier to understand: the Foundation isn't simply pushing people and projects out, nor is it abandoning central coordination; rather, it might be distributing the Ethereum roadmap across more organizations to shoulder together.


Summary


Therefore, Glamsterdam shouldn't be seen merely as a set of EIPs. It is a significant engineering reorganization by Ethereum before achieving higher throughput: who builds blocks, who proposes them, who validates them, which data must be stored long-term, and which resources should be more expensive are all being re-examined.


The keywords for the technical route are ePBS, BAL, and the beginning of multi-dimensional gas; the keywords for the organizational route are more pragmatic: can the Ethereum Foundation maintain its coordinating power, and can new organizations outside the Foundation turn this coordinating power into sustained delivery.


References:
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122

Crypto di tendenza

Domande pertinenti

QWhat is the core purpose of the Glamsterdam upgrade for Ethereum?

AThe Glamsterdam upgrade is not simply about increasing throughput. Its core purpose is to restructure key processes like block production, validation, and resource pricing to pave the way for higher gas limits, larger blob capacity, and future parallel transaction execution. It aims to handle more transactions while preventing uncontrolled growth in block propagation time, verification pressure, and state storage size.

QWhat is ePBS (EIP-7732) and why is it significant in Glamsterdam?

AePBS (Enshrined Proposer-Builder Separation) formally encodes the division of labor between block proposers and block builders into the Ethereum protocol. Proposers choose consensus blocks, while builders prepare the transaction content. Builders must provide collateral and their execution payload, which is verified by a Payload Timeliness Committee (PTC). This reduces reliance on external relays like MEV-Boost and crucially extends the execution payload propagation window from ~2 seconds to ~9 seconds. This longer window allows for safer processing of larger block capacities without increasing the risk of missed votes or reorgs.

QHow does the Block-Level Access List (BAL, EIP-7928) facilitate future scaling?

AThe Block-Level Access List (BAL) attaches a detailed 'access record' to each block, listing every account and storage slot touched during execution and their resulting states. This allows nodes to know in advance which data needs to be read, enabling parallel disk reads, parallel transaction verification, and parallel state root calculations. By making data access patterns explicit, BAL creates an engineering foundation for parallel execution, allowing the network to process blocks faster and more efficiently, which is critical for handling higher transaction loads.

QWhy is EIP-8037 (increasing state creation cost) necessary alongside capacity increases?

AEIP-8037 is necessary to decouple the cost of 'permanent database occupancy' (state growth) from the cost of 'temporary computation'. State (like new accounts and contracts) persists indefinitely on all nodes, leading to database bloat and increased hardware costs that threaten decentralization. With projections showing state growth could exceed performance thresholds under higher gas limits, EIP-8037 significantly raises the gas cost for creating new state. This allows execution capacity (transactions per block) to increase more aggressively while preventing the state database from expanding at an unsustainable rate.

QWhat are the potential implications of the recent Ethereum Foundation personnel changes for the Glamsterdam upgrade and Ethereum's development?

AThe recent changes, including the departure of key figures and the promotion of new protocol cluster coordinators, have sparked debate. Some see it as a potential 'brain drain' that could slow progress. However, the Ethereum Foundation's official narrative frames it as part of a strategic shift towards a 'coalition of organizations' (like ethlabs, Eth Apps Guild, Ethereum Economic Zone, and Argot) sharing the responsibility for executing Ethereum's roadmap. The implication is that the Foundation aims to distribute coordination and development efforts more broadly across the ecosystem, which could enhance resilience and execution capacity in the long term, albeit with potential short-term transition challenges.

Letture associate

A Threefold Performance Leap! NEAR Achieves 200ms Physical Block Time Limit with SPICE

NEAR's core development team, Near One, has announced its next major protocol evolution: SPICE (Separation of Consensus and Execution). Currently in development, SPICE represents the most significant upgrade before the full implementation of Nightshade 3.0. Its core innovation is decoupling the consensus layer, responsible for ordering transactions, from the execution layer, which processes them. This allows the consensus layer to run at full speed without waiting for transaction execution to complete. Once deployed, SPICE is projected to triple NEAR's block production speed, achieving a 200ms block time, which is considered the physical limit due to the speed of light and network latency. This leap will dramatically reduce transaction latency and finality, with transactions confirming in roughly 0.4 seconds—faster than a typical card payment. The upgrade also enables more complex, long-running transactions and significantly improves user experience for applications like NEAR Intents and near.com. Beyond raw speed, SPICE enhances network scalability and security. It enables deeper parallelism, efficiently distributing workload across shards and improving resource utilization. The simpler block structure and lighter contracts also facilitate formal verification and security auditing. Furthermore, SPICE lays the critical groundwork for future Nightshade 3.0 features, most notably atomic cross-shard transactions, which would simplify complex contract logic and eliminate development hurdles caused by asynchronous execution. The Near One team is actively developing SPICE, targeting deployment in the coming months.

Foresight News56 min fa

A Threefold Performance Leap! NEAR Achieves 200ms Physical Block Time Limit with SPICE

Foresight News56 min fa

Deep Insight: Decentralized Inference is Not Hype, but a Key Track for AI to Break Through Centralized Monopoly

Decentralized Reasoning: Beyond the Hype, a Key to Breaking AI's Centralized Monopoly A future scenario where a powerful AI model is banned by a major government illustrates the core value proposition of decentralized AI: resistance to censorship. The core bet of decentralized inference networks is mitigating this risk, with other benefits like cost being secondary. The path is extremely difficult, involving four key challenges: 1. **Running Massive Models:** Distributing a single model across a decentralized GPU swarm requires sophisticated techniques like pipeline and speculative decoding to overcome crippling network latency, aiming for usable speeds (e.g., 30-40 tokens/second). 2. **Proving Model Integrity:** Verifying that a node runs the correct model is critical. Solutions range from cryptographically secure but slow ZKML to faster, economically-secure methods like statistical fingerprints, deterministic re-execution, or live-weight proofs, each involving trade-offs between integrity, latency, and cost. 3. **Ensuring Prompt Privacy:** Simply sharding a model does not protect user inputs from nodes. Robust solutions currently require trusted hardware (TEEs) or advanced cryptography (FHE), which are not yet widely deployed in consumer swarms. 4. **Building a Real Market:** Identifying the ideal customer is tough. Beyond speculative AI agents, the viable market currently consists of startups embedding AI and projects needing batch processing (e.g., synthetic data generation), where decentralized aggregation can be an advantage over low-latency needs. The article analyzes several projects tackling these problems, such as Dolphin Network (live-weight proofs), Inference.net (statistical verification), Morpheus (TEE-based), and Darkbloom (Apple Secure Enclave). It provides a framework: decentralization is a "tax" for latency-sensitive applications (e.g., chat) but a potential supply-side advantage for throughput-oriented tasks (e.g., batch processing). The long-term vision is a closed data loop where decentralized inference generates valuable data (traces, preferences) to feed decentralized training networks, which in turn produce better open-weight models for the inference networks. A due diligence checklist advises focusing on projects that: are truly decentralized at specific layers; have a credible integrity method; offer real cost benefits; ensure genuine privacy; handle node reliability; have paying users; and are built by teams with deep AI expertise. The ultimate goal should be products that appeal beyond the crypto-native audience, using crypto mechanisms invisibly to deliver better cost, performance, or privacy.

Foresight News1 h fa

Deep Insight: Decentralized Inference is Not Hype, but a Key Track for AI to Break Through Centralized Monopoly

Foresight News1 h fa

Trading

Spot
Futures

Articoli Popolari

Cosa è $S$

Comprendere SPERO: Una Panoramica Completa Introduzione a SPERO Mentre il panorama dell'innovazione continua a evolversi, l'emergere delle tecnologie web3 e dei progetti di criptovaluta gioca un ruolo fondamentale nel plasmare il futuro digitale. Un progetto che ha attirato l'attenzione in questo campo dinamico è SPERO, denotato come SPERO,$$s$. Questo articolo mira a raccogliere e presentare informazioni dettagliate su SPERO, per aiutare gli appassionati e gli investitori a comprendere le sue basi, obiettivi e innovazioni nei domini web3 e crypto. Che cos'è SPERO,$$s$? SPERO,$$s$ è un progetto unico all'interno dello spazio crypto che cerca di sfruttare i principi della decentralizzazione e della tecnologia blockchain per creare un ecosistema che promuove l'impegno, l'utilità e l'inclusione finanziaria. Il progetto è progettato per facilitare interazioni peer-to-peer in modi nuovi, fornendo agli utenti soluzioni e servizi finanziari innovativi. Al suo interno, SPERO,$$s$ mira a responsabilizzare gli individui fornendo strumenti e piattaforme che migliorano l'esperienza dell'utente nello spazio delle criptovalute. Questo include la possibilità di metodi di transazione più flessibili, la promozione di iniziative guidate dalla comunità e la creazione di percorsi per opportunità finanziarie attraverso applicazioni decentralizzate (dApps). La visione sottostante di SPERO,$$s$ ruota attorno all'inclusività, cercando di colmare le lacune all'interno della finanza tradizionale mentre sfrutta i vantaggi della tecnologia blockchain. Chi è il Creatore di SPERO,$$s$? L'identità del creatore di SPERO,$$s$ rimane piuttosto oscura, poiché ci sono risorse pubblicamente disponibili limitate che forniscono informazioni dettagliate sul suo fondatore o fondatori. Questa mancanza di trasparenza può derivare dall'impegno del progetto per la decentralizzazione—un ethos che molti progetti web3 condividono, dando priorità ai contributi collettivi rispetto al riconoscimento individuale. Centrando le discussioni attorno alla comunità e ai suoi obiettivi collettivi, SPERO,$$s$ incarna l'essenza dell'empowerment senza mettere in evidenza individui specifici. Pertanto, comprendere l'etica e la missione di SPERO rimane più importante che identificare un creatore singolo. Chi sono gli Investitori di SPERO,$$s$? SPERO,$$s$ è supportato da una varietà di investitori che vanno dai capitalisti di rischio agli investitori angelici dedicati a promuovere l'innovazione nel settore crypto. Il focus di questi investitori generalmente si allinea con la missione di SPERO—dando priorità a progetti che promettono avanzamenti tecnologici sociali, inclusività finanziaria e governance decentralizzata. Queste fondazioni di investitori sono tipicamente interessate a progetti che non solo offrono prodotti innovativi, ma contribuiscono anche positivamente alla comunità blockchain e ai suoi ecosistemi. Il supporto di questi investitori rafforza SPERO,$$s$ come un concorrente degno di nota nel dominio in rapida evoluzione dei progetti crypto. Come Funziona SPERO,$$s$? SPERO,$$s$ impiega un framework multifunzionale che lo distingue dai progetti di criptovaluta convenzionali. Ecco alcune delle caratteristiche chiave che sottolineano la sua unicità e innovazione: Governance Decentralizzata: SPERO,$$s$ integra modelli di governance decentralizzati, responsabilizzando gli utenti a partecipare attivamente ai processi decisionali riguardanti il futuro del progetto. Questo approccio favorisce un senso di proprietà e responsabilità tra i membri della comunità. Utilità del Token: SPERO,$$s$ utilizza il proprio token di criptovaluta, progettato per servire varie funzioni all'interno dell'ecosistema. Questi token abilitano transazioni, premi e la facilitazione dei servizi offerti sulla piattaforma, migliorando l'impegno e l'utilità complessivi. Architettura Stratificata: L'architettura tecnica di SPERO,$$s$ supporta la modularità e la scalabilità, consentendo un'integrazione fluida di funzionalità e applicazioni aggiuntive man mano che il progetto evolve. Questa adattabilità è fondamentale per mantenere la rilevanza nel panorama crypto in continua evoluzione. Coinvolgimento della Comunità: Il progetto enfatizza iniziative guidate dalla comunità, impiegando meccanismi che incentivano la collaborazione e il feedback. Nutrendo una comunità forte, SPERO,$$s$ può affrontare meglio le esigenze degli utenti e adattarsi alle tendenze di mercato. Focus sull'Inclusione: Offrendo basse commissioni di transazione e interfacce user-friendly, SPERO,$$s$ mira ad attrarre una base utenti diversificata, inclusi individui che potrebbero non aver precedentemente interagito nello spazio crypto. Questo impegno per l'inclusione si allinea con la sua missione generale di empowerment attraverso l'accessibilità. Cronologia di SPERO,$$s$ Comprendere la storia di un progetto fornisce preziose intuizioni sulla sua traiettoria di sviluppo e sui traguardi. Di seguito è riportata una cronologia suggerita che mappa eventi significativi nell'evoluzione di SPERO,$$s$: Fase di Concettualizzazione e Ideazione: Le idee iniziali che formano la base di SPERO,$$s$ sono state concepite, allineandosi strettamente con i principi di decentralizzazione e focus sulla comunità all'interno dell'industria blockchain. Lancio del Whitepaper del Progetto: Dopo la fase concettuale, è stato rilasciato un whitepaper completo che dettaglia la visione, gli obiettivi e l'infrastruttura tecnologica di SPERO,$$s$ per suscitare interesse e feedback dalla comunità. Costruzione della Comunità e Prime Interazioni: Sono stati effettuati sforzi attivi di outreach per costruire una comunità di early adopters e potenziali investitori, facilitando discussioni attorno agli obiettivi del progetto e ottenendo supporto. Evento di Generazione del Token: SPERO,$$s$ ha condotto un evento di generazione del token (TGE) per distribuire i propri token nativi ai primi sostenitori e stabilire una liquidità iniziale all'interno dell'ecosistema. Lancio della Prima dApp: La prima applicazione decentralizzata (dApp) associata a SPERO,$$s$ è stata attivata, consentendo agli utenti di interagire con le funzionalità principali della piattaforma. Sviluppo Continuo e Partnership: Aggiornamenti e miglioramenti continui alle offerte del progetto, inclusi partnership strategiche con altri attori nello spazio blockchain, hanno plasmato SPERO,$$s$ in un concorrente competitivo e in evoluzione nel mercato crypto. Conclusione SPERO,$$s$ rappresenta una testimonianza del potenziale del web3 e delle criptovalute di rivoluzionare i sistemi finanziari e responsabilizzare gli individui. Con un impegno per la governance decentralizzata, il coinvolgimento della comunità e funzionalità progettate in modo innovativo, apre la strada verso un panorama finanziario più inclusivo. Come per qualsiasi investimento nello spazio crypto in rapida evoluzione, si incoraggiano potenziali investitori e utenti a ricercare approfonditamente e a impegnarsi in modo riflessivo con gli sviluppi in corso all'interno di SPERO,$$s$. Il progetto mostra lo spirito innovativo dell'industria crypto, invitando a ulteriori esplorazioni delle sue innumerevoli possibilità. Mentre il percorso di SPERO,$$s$ è ancora in fase di sviluppo, i suoi principi fondamentali potrebbero effettivamente influenzare il futuro di come interagiamo con la tecnologia, la finanza e tra di noi in ecosistemi digitali interconnessi.

87 Totale visualizzazioniPubblicato il 2024.12.17Aggiornato il 2024.12.17

Cosa è $S$

Cosa è AGENT S

Agent S: Il Futuro dell'Interazione Autonoma in Web3 Introduzione Nel panorama in continua evoluzione di Web3 e criptovalute, le innovazioni stanno costantemente ridefinendo il modo in cui gli individui interagiscono con le piattaforme digitali. Uno di questi progetti pionieristici, Agent S, promette di rivoluzionare l'interazione uomo-computer attraverso il suo framework agentico aperto. Aprendo la strada a interazioni autonome, Agent S mira a semplificare compiti complessi, offrendo applicazioni trasformative nell'intelligenza artificiale (AI). Questa esplorazione dettagliata approfondirà le complessità del progetto, le sue caratteristiche uniche e le implicazioni per il dominio delle criptovalute. Cos'è Agent S? Agent S si presenta come un innovativo framework agentico aperto, progettato specificamente per affrontare tre sfide fondamentali nell'automazione dei compiti informatici: Acquisizione di Conoscenze Specifiche del Dominio: Il framework apprende in modo intelligente da varie fonti di conoscenza esterne ed esperienze interne. Questo approccio duale gli consente di costruire un ricco repository di conoscenze specifiche del dominio, migliorando le sue prestazioni nell'esecuzione dei compiti. Pianificazione su Lungo Orizzonte di Compiti: Agent S impiega una pianificazione gerarchica potenziata dall'esperienza, un approccio strategico che facilita la suddivisione e l'esecuzione efficiente di compiti complessi. Questa caratteristica migliora significativamente la sua capacità di gestire più sottocompiti in modo efficiente ed efficace. Gestione di Interfacce Dinamiche e Non Uniformi: Il progetto introduce l'Interfaccia Agente-Computer (ACI), una soluzione innovativa che migliora l'interazione tra agenti e utenti. Utilizzando Modelli Linguistici Multimodali di Grandi Dimensioni (MLLM), Agent S può navigare e manipolare senza sforzo diverse interfacce grafiche utente. Attraverso queste caratteristiche pionieristiche, Agent S fornisce un framework robusto che affronta le complessità coinvolte nell'automazione dell'interazione umana con le macchine, preparando il terreno per innumerevoli applicazioni nell'AI e oltre. Chi è il Creatore di Agent S? Sebbene il concetto di Agent S sia fondamentalmente innovativo, informazioni specifiche sul suo creatore rimangono elusive. Il creatore è attualmente sconosciuto, il che evidenzia sia la fase embrionale del progetto sia la scelta strategica di mantenere i membri fondatori sotto anonimato. Indipendentemente dall'anonimato, l'attenzione rimane sulle capacità e sul potenziale del framework. Chi sono gli Investitori di Agent S? Poiché Agent S è relativamente nuovo nell'ecosistema crittografico, informazioni dettagliate riguardanti i suoi investitori e sostenitori finanziari non sono documentate esplicitamente. La mancanza di approfondimenti pubblicamente disponibili sulle fondazioni di investimento o sulle organizzazioni che supportano il progetto solleva interrogativi sulla sua struttura di finanziamento e sulla roadmap di sviluppo. Comprendere il supporto è cruciale per valutare la sostenibilità del progetto e il suo potenziale impatto sul mercato. Come Funziona Agent S? Al centro di Agent S si trova una tecnologia all'avanguardia che gli consente di funzionare efficacemente in contesti diversi. Il suo modello operativo è costruito attorno a diverse caratteristiche chiave: Interazione Uomo-Computer Simile a Quella Umana: Il framework offre una pianificazione AI avanzata, cercando di rendere le interazioni con i computer più intuitive. Mimando il comportamento umano nell'esecuzione dei compiti, promette di elevare le esperienze degli utenti. Memoria Narrativa: Utilizzata per sfruttare esperienze di alto livello, Agent S utilizza la memoria narrativa per tenere traccia delle storie dei compiti, migliorando così i suoi processi decisionali. Memoria Episodica: Questa caratteristica fornisce agli utenti una guida passo-passo, consentendo al framework di offrire supporto contestuale mentre i compiti si sviluppano. Supporto per OpenACI: Con la capacità di funzionare localmente, Agent S consente agli utenti di mantenere il controllo sulle proprie interazioni e flussi di lavoro, allineandosi con l'etica decentralizzata di Web3. Facile Integrazione con API Esterne: La sua versatilità e compatibilità con varie piattaforme AI garantiscono che Agent S possa adattarsi senza problemi agli ecosistemi tecnologici esistenti, rendendolo una scelta attraente per sviluppatori e organizzazioni. Queste funzionalità contribuiscono collettivamente alla posizione unica di Agent S all'interno dello spazio crittografico, poiché automatizza compiti complessi e multi-fase con un intervento umano minimo. Man mano che il progetto evolve, le sue potenziali applicazioni in Web3 potrebbero ridefinire il modo in cui si svolgono le interazioni digitali. Cronologia di Agent S Lo sviluppo e le tappe di Agent S possono essere riassunti in una cronologia che evidenzia i suoi eventi significativi: 27 Settembre 2024: Il concetto di Agent S è stato lanciato in un documento di ricerca completo intitolato “Un Framework Agentico Aperto che Usa i Computer Come un Umano”, mostrando le basi per il progetto. 10 Ottobre 2024: Il documento di ricerca è stato reso pubblicamente disponibile su arXiv, offrendo un'esplorazione approfondita del framework e della sua valutazione delle prestazioni basata sul benchmark OSWorld. 12 Ottobre 2024: È stata rilasciata una presentazione video, fornendo un'idea visiva delle capacità e delle caratteristiche di Agent S, coinvolgendo ulteriormente potenziali utenti e investitori. Questi indicatori nella cronologia non solo illustrano i progressi di Agent S, ma indicano anche il suo impegno per la trasparenza e il coinvolgimento della comunità. Punti Chiave su Agent S Man mano che il framework Agent S continua a evolversi, diversi attributi chiave si distinguono, sottolineando la sua natura innovativa e il potenziale: Framework Innovativo: Progettato per fornire un uso intuitivo dei computer simile all'interazione umana, Agent S porta un approccio nuovo all'automazione dei compiti. Interazione Autonoma: La capacità di interagire autonomamente con i computer attraverso GUI segna un passo avanti verso soluzioni informatiche più intelligenti ed efficienti. Automazione di Compiti Complessi: Con la sua metodologia robusta, può automatizzare compiti complessi e multi-fase, rendendo i processi più veloci e meno soggetti a errori. Miglioramento Continuo: I meccanismi di apprendimento consentono ad Agent S di migliorare dalle esperienze passate, migliorando continuamente le sue prestazioni e la sua efficacia. Versatilità: La sua adattabilità attraverso diversi ambienti operativi come OSWorld e WindowsAgentArena garantisce che possa servire un'ampia gamma di applicazioni. Man mano che Agent S si posiziona nel panorama di Web3 e delle criptovalute, il suo potenziale per migliorare le capacità di interazione e automatizzare i processi segna un significativo avanzamento nelle tecnologie AI. Attraverso il suo framework innovativo, Agent S esemplifica il futuro delle interazioni digitali, promettendo un'esperienza più fluida ed efficiente per gli utenti in vari settori. Conclusione Agent S rappresenta un audace passo avanti nell'unione tra AI e Web3, con la capacità di ridefinire il modo in cui interagiamo con la tecnologia. Sebbene sia ancora nelle sue fasi iniziali, le possibilità per la sua applicazione sono vaste e coinvolgenti. Attraverso il suo framework completo che affronta sfide critiche, Agent S mira a portare le interazioni autonome al centro dell'esperienza digitale. Man mano che ci addentriamo nei regni delle criptovalute e della decentralizzazione, progetti come Agent S giocheranno senza dubbio un ruolo cruciale nel plasmare il futuro della tecnologia e della collaborazione uomo-computer.

554 Totale visualizzazioniPubblicato il 2025.01.14Aggiornato il 2025.01.14

Cosa è AGENT S

Come comprare S

Benvenuto in HTX.com! Abbiamo reso l'acquisto di Sonic (S) semplice e conveniente. Segui la nostra guida passo passo per intraprendere il tuo viaggio nel mondo delle criptovalute.Step 1: Crea il tuo Account HTXUsa la tua email o numero di telefono per registrarti il tuo account gratuito su HTX. Vivi un'esperienza facile e sblocca tutte le funzionalità,Crea il mio accountStep 2: Vai in Acquista crypto e seleziona il tuo metodo di pagamentoCarta di credito/debito: utilizza la tua Visa o Mastercard per acquistare immediatamente SonicS.Bilancio: Usa i fondi dal bilancio del tuo account HTX per fare trading senza problemi.Terze parti: abbiamo aggiunto metodi di pagamento molto utilizzati come Google Pay e Apple Pay per maggiore comodità.P2P: Fai trading direttamente con altri utenti HTX.Over-the-Counter (OTC): Offriamo servizi su misura e tassi di cambio competitivi per i trader.Step 3: Conserva Sonic (S)Dopo aver acquistato Sonic (S), conserva nel tuo account HTX. In alternativa, puoi inviare tramite trasferimento blockchain o scambiare per altre criptovalute.Step 4: Scambia Sonic (S)Scambia facilmente Sonic (S) nel mercato spot di HTX. Accedi al tuo account, seleziona la tua coppia di trading, esegui le tue operazioni e monitora in tempo reale. Offriamo un'esperienza user-friendly sia per chi ha appena iniziato che per i trader più esperti.

1.1k Totale visualizzazioniPubblicato il 2025.01.15Aggiornato il 2026.06.02

Come comprare S

Discussioni

Benvenuto nella Community HTX. Qui puoi rimanere informato sugli ultimi sviluppi della piattaforma e accedere ad approfondimenti esperti sul mercato. Le opinioni degli utenti sul prezzo di S S sono presentate come di seguito.

活动图片