# ⚙️ GLAMSTERDAM : Ethereum viết lại cơ chế sản xuất khối, và DVT trở thành một hạ tầng quan trọng
Fusaka (tháng 12/2025) đã mở rộng khả năng sẵn sàng dữ liệu (data availability) với PeerDAS. Glamsterdam (mục tiêu: Q3 2026, cửa sổ nội bộ kết thúc vào cuối tháng 8) tấn công vào “trái tim” của lò phản ứng: việc xây dựng và thực thi các khối. Hai EIP tiêu điểm, và một hệ quả trực tiếp cho kiến trúc của các trình xác thực. Chủ đề kỹ thuật. 🧵
---
## 1️⃣ EIP-7732 : ePBS (Tách biệt Người đề xuất - Người xây dựng được ghi vào giao thức)
Ngày nay, 80-90% các khối Ethereum đi qua các relay bên ngoài thuộc loại MEV-Boost. Đây là một điểm tin cậy nằm ngoài giao thức, nên là một vector tập trung hóa.
ePBS nhúng việc tách proposer/builder vào trong giao thức:
- Các cuộc đấu giá, cam kết và thanh toán của builder trở nên trustless và nằm trong giao thức → loại bỏ lớp middleware dựa trên niềm tin
- Cửa sổ lan truyền payload tăng từ ~2s lên ~9s → mở khóa các payload nặng hơn nhiều và nhiều blob hơn trong các fork BPO tương lai
- Duty mới của validator: PTC (Payload Timeliness Committee), chứng thực riêng về tính kịp thời của payload thông qua một logic với hai mốc deadline
👉 Điểm mấu chốt: giao thức giờ phải xử lý việc không giao được hoặc bất đồng giữa hai bên tuần tự trong consensus ("partial blocks"). Đây là LÝ DO khiến Glamsterdam tiến chậm hơn Fusaka.
## 2️⃣ EIP-7928 : BALs (Danh sách truy cập theo cấp khối)
Việc thực thi hiện nay là tuần tự: không node nào biết trước tx sẽ chạm tới những tài khoản/slot storage nào trước khi thực thi.
BALs gắn cho mỗi khối một “bản đồ” truy cập state đã được khai báo trước (tài khoản + các khóa storage + các giá trị sau khi thực thi):
- Prefetch state song song
- Thực thi đồng thời các tx không xung đột
- Có thể đồng bộ “executionless”
👉 Đây là đòn bẩy để nhắm tới gas limit từ 60M → 200M (đang chạy test với mốc tham chiếu 150M), với EIP-8037 định giá lại chi phí tạo state nhằm kiềm chế tình trạng phình state.
## 3️⃣ OBOL tham gia vào đâu
Glamsterdam thay đổi nghề nghiệp của người xác thực: duty mới về chứng thực PTC, ràng buộc về độ trễ và uptime tăng lên, phần cứng đòi hỏi cao hơn một chút (đọc đĩa song song). Mỗi mili giây về tính sẵn sàng giờ quan trọng hơn.
Đúng là vấn đề mà DVT (Distributed Validator Technology) của Obol giải quyết:
- Charon: middleware tách khóa BLS của một validator bằng DKG giữa nhiều operator độc lập
- Chữ ký theo ngưỡng: cụm vẫn vận hành chừng nào ≥66% các node còn up (dự phòng active/active, không có khóa đầy đủ nào tồn tại ở runtime)
- Đa dạng client gốc → khả năng chống lỗi của client, quan trọng khi TẤT CẢ các CL/EL đều phải ship ePBS ngang bằng
📊 Tình hình hiện tại: ~600.000 ETH (~$2B) được triển khai trên các Distributed Validators, ~1,6% lượng ETH được stake, với mục tiêu công bố là 10% vào cuối 2026. Mức độ áp dụng: Lido CSM v2 (~70% ứng viên ICS thông qua Obol Techne), EtherFi, Bitcoin Suisse, và một đợt triển khai chủ quyền đầu tiên (LTIN, Liechtenstein).
## 4️⃣ Luận điểm
Sau Glamsterdam, một validator chạy trên một máy đơn mà bỏ lỡ cửa sổ PTC hoặc chứng thực của mình sẽ trở thành một chi phí đo lường được. Các cụm DV chịu lỗi trở thành kiến trúc mặc định cho staking mang tính tổ chức, đúng vào thời điểm các ETF được stake đẩy các định chế hướng tới yield on-chain.
⚠️ Rủi ro, không có bộ lọc:
- Dòng thời gian : ePBS phức tạp, trễ một chút sang Q4 2026 là điều khả thi (sự cân bằng giữa các client là điểm nghẽn)
- Token OBOL vẫn là một canh bạc để nắm bắt giá trị trong tương lai: hạ tầng đã được áp dụng, nhưng mối liên hệ kinh tế giữa token ↔ TVL (Economic Engine) vẫn đang được xây dựng, và các đợt unlock vào 2026 sẽ tạo áp lực
- Hạ tầng ≠ token. Hãy phân biệt điều đó khi bạn định cỡ (sizing).
---
Nâng cấp quan trọng nhất kể từ The Merge định nghĩa lại cách xây dựng các khối và chúng được thực thi như thế nào. Không phải vấn đề là việc staking có được phi tập trung theo các cụm (việc đó đã đang diễn ra), mà là ai nắm bắt giá trị từ sự chuyển đổi này.
DYOR. Không phải lời khuyên tài chính.