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

Foresight NewsPublicado a 2026-06-23Actualizado a 2026-06-23

Resumen

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

Criptos en tendencia

Preguntas relacionadas

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.

Lecturas Relacionadas

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 NewsHace 58 min(s)

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

Foresight NewsHace 58 min(s)

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 NewsHace 1 hora(s)

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

Foresight NewsHace 1 hora(s)

Trading

Spot
Futuros

Artículos destacados

Qué es $S$

Entendiendo SPERO: Una Visión General Completa Introducción a SPERO A medida que el panorama de la innovación continúa evolucionando, la aparición de tecnologías web3 y proyectos de criptomonedas juega un papel fundamental en la configuración del futuro digital. Un proyecto que ha atraído la atención en este campo dinámico es SPERO, denotado como SPERO,$$s$. Este artículo tiene como objetivo reunir y presentar información detallada sobre SPERO, para ayudar a entusiastas e inversores a comprender sus fundamentos, objetivos e innovaciones dentro de los dominios web3 y cripto. ¿Qué es SPERO,$$s$? SPERO,$$s$ es un proyecto único dentro del espacio cripto que busca aprovechar los principios de descentralización y tecnología blockchain para crear un ecosistema que promueva la participación, la utilidad y la inclusión financiera. El proyecto está diseñado para facilitar interacciones de igual a igual de nuevas maneras, proporcionando a los usuarios soluciones y servicios financieros innovadores. En su esencia, SPERO,$$s$ tiene como objetivo empoderar a los individuos al proporcionar herramientas y plataformas que mejoren la experiencia del usuario en el espacio de las criptomonedas. Esto incluye habilitar métodos de transacción más flexibles, fomentar iniciativas impulsadas por la comunidad y crear caminos para oportunidades financieras a través de aplicaciones descentralizadas (dApps). La visión subyacente de SPERO,$$s$ gira en torno a la inclusividad, buscando cerrar brechas dentro de las finanzas tradicionales mientras aprovecha los beneficios de la tecnología blockchain. ¿Quién es el Creador de SPERO,$$s$? La identidad del creador de SPERO,$$s$ sigue siendo algo oscura, ya que hay recursos públicos limitados que proporcionan información de fondo detallada sobre su(s) fundador(es). Esta falta de transparencia puede derivarse del compromiso del proyecto con la descentralización, una ética que muchos proyectos web3 comparten, priorizando las contribuciones colectivas sobre el reconocimiento individual. Al centrar las discusiones en torno a la comunidad y sus objetivos colectivos, SPERO,$$s$ encarna la esencia del empoderamiento sin señalar a individuos específicos. Como tal, comprender la ética y la misión de SPERO sigue siendo más importante que identificar a un creador singular. ¿Quiénes son los Inversores de SPERO,$$s$? SPERO,$$s$ cuenta con el apoyo de una diversa gama de inversores que van desde capitalistas de riesgo hasta inversores ángeles dedicados a fomentar la innovación en el sector cripto. El enfoque de estos inversores generalmente se alinea con la misión de SPERO, priorizando proyectos que prometen avances tecnológicos sociales, inclusión financiera y gobernanza descentralizada. Estas fundaciones de inversores suelen estar interesadas en proyectos que no solo ofrecen productos innovadores, sino que también contribuyen positivamente a la comunidad blockchain y sus ecosistemas. El respaldo de estos inversores refuerza a SPERO,$$s$ como un contendiente notable en el dominio de proyectos cripto que evoluciona rápidamente. ¿Cómo Funciona SPERO,$$s$? SPERO,$$s$ emplea un marco multifacético que lo distingue de los proyectos de criptomonedas convencionales. Aquí hay algunas de las características clave que subrayan su singularidad e innovación: Gobernanza Descentralizada: SPERO,$$s$ integra modelos de gobernanza descentralizada, empoderando a los usuarios para participar activamente en los procesos de toma de decisiones sobre el futuro del proyecto. Este enfoque fomenta un sentido de propiedad y responsabilidad entre los miembros de la comunidad. Utilidad del Token: SPERO,$$s$ utiliza su propio token de criptomoneda, diseñado para servir diversas funciones dentro del ecosistema. Estos tokens permiten transacciones, recompensas y la facilitación de servicios ofrecidos en la plataforma, mejorando la participación y la utilidad general. Arquitectura en Capas: La arquitectura técnica de SPERO,$$s$ apoya la modularidad y escalabilidad, permitiendo la integración fluida de características y aplicaciones adicionales a medida que el proyecto evoluciona. Esta adaptabilidad es fundamental para mantener la relevancia en el cambiante paisaje cripto. Participación de la Comunidad: El proyecto enfatiza iniciativas impulsadas por la comunidad, empleando mecanismos que incentivan la colaboración y la retroalimentación. Al nutrir una comunidad sólida, SPERO,$$s$ puede abordar mejor las necesidades de los usuarios y adaptarse a las tendencias del mercado. Enfoque en la Inclusión: Al ofrecer tarifas de transacción bajas e interfaces amigables para el usuario, SPERO,$$s$ busca atraer a una base de usuarios diversa, incluyendo a individuos que anteriormente pueden no haber participado en el espacio cripto. Este compromiso con la inclusión se alinea con su misión general de empoderamiento a través de la accesibilidad. Cronología de SPERO,$$s$ Entender la historia de un proyecto proporciona información crucial sobre su trayectoria de desarrollo y hitos. A continuación se presenta una cronología sugerida que mapea eventos significativos en la evolución de SPERO,$$s$: Fase de Conceptualización e Ideación: Las ideas iniciales que forman la base de SPERO,$$s$ fueron concebidas, alineándose estrechamente con los principios de descentralización y enfoque comunitario dentro de la industria blockchain. Lanzamiento del Whitepaper del Proyecto: Tras la fase conceptual, se lanzó un whitepaper completo que detalla la visión, los objetivos y la infraestructura tecnológica de SPERO,$$s$ para generar interés y retroalimentación de la comunidad. Construcción de Comunidad y Primeras Interacciones: Se realizaron esfuerzos de divulgación activa para construir una comunidad de primeros adoptantes y posibles inversores, facilitando discusiones en torno a los objetivos del proyecto y obteniendo apoyo. Evento de Generación de Tokens: SPERO,$$s$ llevó a cabo un evento de generación de tokens (TGE) para distribuir sus tokens nativos a los primeros seguidores y establecer liquidez inicial dentro del ecosistema. Lanzamiento de la dApp Inicial: La primera aplicación descentralizada (dApp) asociada con SPERO,$$s$ se puso en marcha, permitiendo a los usuarios interactuar con las funcionalidades centrales de la plataforma. Desarrollo Continuo y Alianzas: Actualizaciones y mejoras continuas a las ofertas del proyecto, incluyendo alianzas estratégicas con otros actores en el espacio blockchain, han moldeado a SPERO,$$s$ en un jugador competitivo y en evolución en el mercado cripto. Conclusión SPERO,$$s$ se erige como un testimonio del potencial de web3 y las criptomonedas para revolucionar los sistemas financieros y empoderar a los individuos. Con un compromiso con la gobernanza descentralizada, la participación comunitaria y funcionalidades diseñadas de manera innovadora, allana el camino hacia un paisaje financiero más inclusivo. Como con cualquier inversión en el espacio cripto que evoluciona rápidamente, se anima a los posibles inversores y usuarios a investigar a fondo y participar de manera reflexiva con los desarrollos en curso dentro de SPERO,$$s$. El proyecto muestra el espíritu innovador de la industria cripto, invitando a una mayor exploración de sus innumerables posibilidades. Mientras el viaje de SPERO,$$s$ aún se desarrolla, sus principios fundamentales pueden, de hecho, influir en el futuro de cómo interactuamos con la tecnología, las finanzas y entre nosotros en ecosistemas digitales interconectados.

87 Vistas totalesPublicado en 2024.12.17Actualizado en 2024.12.17

Qué es $S$

Qué es AGENT S

Agent S: El Futuro de la Interacción Autónoma en Web3 Introducción En el paisaje en constante evolución de Web3 y las criptomonedas, las innovaciones están redefiniendo constantemente cómo los individuos interactúan con las plataformas digitales. Uno de estos proyectos pioneros, Agent S, promete revolucionar la interacción humano-computadora a través de su marco agente abierto. Al allanar el camino para interacciones autónomas, Agent S busca simplificar tareas complejas, ofreciendo aplicaciones transformadoras en inteligencia artificial (IA). Esta exploración detallada profundizará en las complejidades del proyecto, sus características únicas y las implicaciones para el dominio de las criptomonedas. ¿Qué es Agent S? Agent S se presenta como un marco agente abierto innovador, diseñado específicamente para abordar tres desafíos fundamentales en la automatización de tareas informáticas: Adquisición de Conocimiento Específico del Dominio: El marco aprende inteligentemente de diversas fuentes de conocimiento externas y experiencias internas. Este enfoque dual le permite construir un rico repositorio de conocimiento específico del dominio, mejorando su rendimiento en la ejecución de tareas. Planificación a Largo Plazo de Tareas: Agent S emplea planificación jerárquica aumentada por la experiencia, un enfoque estratégico que facilita la descomposición y ejecución eficiente de tareas complejas. Esta característica mejora significativamente su capacidad para gestionar múltiples subtareas de manera eficiente y efectiva. Manejo de Interfaces Dinámicas y No Uniformes: El proyecto introduce la Interfaz Agente-Computadora (ACI), una solución innovadora que mejora la interacción entre agentes y usuarios. Utilizando Modelos de Lenguaje Multimodal de Gran Escala (MLLMs), Agent S puede navegar y manipular diversas interfaces gráficas de usuario sin problemas. A través de estas características pioneras, Agent S proporciona un marco robusto que aborda las complejidades involucradas en la automatización de la interacción humana con las máquinas, preparando el terreno para una multitud de aplicaciones en IA y más allá. ¿Quién es el Creador de Agent S? Si bien el concepto de Agent S es fundamentalmente innovador, la información específica sobre su creador sigue siendo elusiva. El creador es actualmente desconocido, lo que resalta ya sea la etapa incipiente del proyecto o la elección estratégica de mantener a los miembros fundadores en el anonimato. Independientemente de la anonimidad, el enfoque sigue siendo en las capacidades y el potencial del marco. ¿Quiénes son los Inversores de Agent S? Dado que Agent S es relativamente nuevo en el ecosistema criptográfico, la información detallada sobre sus inversores y patrocinadores financieros no está documentada explícitamente. La falta de información disponible públicamente sobre las bases de inversión u organizaciones que apoyan el proyecto plantea preguntas sobre su estructura de financiamiento y hoja de ruta de desarrollo. Comprender el respaldo es crucial para evaluar la sostenibilidad del proyecto y su posible impacto en el mercado. ¿Cómo Funciona Agent S? En el núcleo de Agent S se encuentra una tecnología de vanguardia que le permite funcionar de manera efectiva en diversos entornos. Su modelo operativo se basa en varias características clave: Interacción Humano-Computadora Similar a la Humana: El marco ofrece planificación avanzada de IA, esforzándose por hacer que las interacciones con las computadoras sean más intuitivas. Al imitar el comportamiento humano en la ejecución de tareas, promete elevar las experiencias de los usuarios. Memoria Narrativa: Empleada para aprovechar experiencias de alto nivel, Agent S utiliza memoria narrativa para hacer un seguimiento de las historias de tareas, mejorando así sus procesos de toma de decisiones. Memoria Episódica: Esta característica proporciona a los usuarios una guía paso a paso, permitiendo que el marco ofrezca apoyo contextual a medida que se desarrollan las tareas. Soporte para OpenACI: Con la capacidad de ejecutarse localmente, Agent S permite a los usuarios mantener el control sobre sus interacciones y flujos de trabajo, alineándose con la ética descentralizada de Web3. Fácil Integración con APIs Externas: Su versatilidad y compatibilidad con varias plataformas de IA aseguran que Agent S pueda encajar sin problemas en ecosistemas tecnológicos existentes, convirtiéndolo en una opción atractiva para desarrolladores y organizaciones. Estas funcionalidades contribuyen colectivamente a la posición única de Agent S dentro del espacio cripto, ya que automatiza tareas complejas y de múltiples pasos con una intervención humana mínima. A medida que el proyecto evoluciona, sus posibles aplicaciones en Web3 podrían redefinir cómo se desarrollan las interacciones digitales. Cronología de Agent S El desarrollo y los hitos de Agent S pueden encapsularse en una cronología que resalta sus eventos significativos: 27 de septiembre de 2024: El concepto de Agent S fue lanzado en un documento de investigación integral titulado “Un Marco Agente Abierto que Usa Computadoras Como un Humano”, mostrando las bases del proyecto. 10 de octubre de 2024: El documento de investigación fue puesto a disposición del público en arXiv, ofreciendo una exploración profunda del marco y su evaluación de rendimiento basada en el benchmark OSWorld. 12 de octubre de 2024: Se lanzó una presentación en video, proporcionando una visión visual de las capacidades y características de Agent S, involucrando aún más a posibles usuarios e inversores. Estos marcadores en la cronología no solo ilustran el progreso de Agent S, sino que también indican su compromiso con la transparencia y la participación comunitaria. Puntos Clave Sobre Agent S A medida que el marco Agent S continúa evolucionando, varios atributos clave destacan, subrayando su naturaleza innovadora y potencial: Marco Innovador: Diseñado para proporcionar un uso intuitivo de las computadoras similar a la interacción humana, Agent S aporta un enfoque novedoso a la automatización de tareas. Interacción Autónoma: La capacidad de interactuar de manera autónoma con las computadoras a través de GUI significa un salto hacia soluciones informáticas más inteligentes y eficientes. Automatización de Tareas Complejas: Con su metodología robusta, puede automatizar tareas complejas y de múltiples pasos, haciendo que los procesos sean más rápidos y menos propensos a errores. Mejora Continua: Los mecanismos de aprendizaje permiten a Agent S mejorar a partir de experiencias pasadas, mejorando continuamente su rendimiento y eficacia. Versatilidad: Su adaptabilidad en diferentes entornos operativos como OSWorld y WindowsAgentArena asegura que pueda servir a una amplia gama de aplicaciones. A medida que Agent S se posiciona en el paisaje de Web3 y criptomonedas, su potencial para mejorar las capacidades de interacción y automatizar procesos significa un avance significativo en las tecnologías de IA. A través de su marco innovador, Agent S ejemplifica el futuro de las interacciones digitales, prometiendo una experiencia más fluida y eficiente para los usuarios en diversas industrias. Conclusión Agent S representa un audaz avance en la unión de la IA y Web3, con la capacidad de redefinir cómo interactuamos con la tecnología. Aunque aún se encuentra en sus primeras etapas, las posibilidades para su aplicación son vastas y atractivas. A través de su marco integral que aborda desafíos críticos, Agent S busca llevar las interacciones autónomas al primer plano de la experiencia digital. A medida que nos adentramos más en los reinos de las criptomonedas y la descentralización, proyectos como Agent S sin duda desempeñarán un papel crucial en la configuración del futuro de la tecnología y la colaboración humano-computadora.

496 Vistas totalesPublicado en 2025.01.14Actualizado en 2025.01.14

Qué es AGENT S

Cómo comprar S

¡Bienvenido a HTX.com! Hemos hecho que comprar Sonic (S) sea simple y conveniente. Sigue nuestra guía paso a paso para iniciar tu viaje de criptos.Paso 1: crea tu cuenta HTXUtiliza tu correo electrónico o número de teléfono para registrarte y obtener una cuenta gratuita en HTX. Experimenta un proceso de registro sin complicaciones y desbloquea todas las funciones.Obtener mi cuentaPaso 2: ve a Comprar cripto y elige tu método de pagoTarjeta de crédito/débito: usa tu Visa o Mastercard para comprar Sonic (S) al instante.Saldo: utiliza fondos del saldo de tu cuenta HTX para tradear sin problemas.Terceros: hemos agregado métodos de pago populares como Google Pay y Apple Pay para mejorar la comodidad.P2P: tradear directamente con otros usuarios en HTX.Over-the-Counter (OTC): ofrecemos servicios personalizados y tipos de cambio competitivos para los traders.Paso 3: guarda tu Sonic (S)Después de comprar tu Sonic (S), guárdalo en tu cuenta HTX. Alternativamente, puedes enviarlo a otro lugar mediante transferencia blockchain o utilizarlo para tradear otras criptomonedas.Paso 4: tradear Sonic (S)Tradear fácilmente con Sonic (S) en HTX's mercado spot. Simplemente accede a tu cuenta, selecciona tu par de trading, ejecuta tus trades y monitorea en tiempo real. Ofrecemos una experiencia fácil de usar tanto para principiantes como para traders experimentados.

1.0k Vistas totalesPublicado en 2025.01.15Actualizado en 2026.06.02

Cómo comprar S

Discusiones

Bienvenido a la comunidad de HTX. Aquí puedes mantenerte informado sobre los últimos desarrollos de la plataforma y acceder a análisis profesionales del mercado. A continuación se presentan las opiniones de los usuarios sobre el precio de S (S).

活动图片