Kemarin hari Jumat Kliwon, 12 Juli 2024 itu adalah hari ulang tahun saya yang 37 tahun, itu berarti saya sudah hidup di bumi ini sudah 13515 hari.
Ketika saya merenung dan berpikir agar perjalanan hidup saya bisa lebih berguna dan bermanfaat bagi orang lain maka saya ingin membangun organisasi
yang bisa saling menguntungkan, mewujudkan keindahan lingkungan dan menggunakan teknologi dengan bijaksana.
Meskipun demikian, setiap organisasi yang memiliki niat awal dengan tujuan baik tidak akan terwujud jika tidak dilaksanakan.
Perjalanan hidup organisasi ibarat pohon yang memiliki ekosistem yang baik, agar pohon tersebut bertahan lama dan berbuah maka harus saling merawat dan menjaga.
Nama Kafe Gunung yang baru terbentuk ini sebagian besar berjalan secara independen, belum memiliki investor, penasihat dan pelanggan.
"Permainan terbatas dimainkan dengan tujuan untuk menang. Permainan tak terbatas dimainkan dengan tujuan untuk melanjutkan permainan."~James P.Carse:
Visi Misi ini, terutama dua yang terakhir, merupakan pendahulu penting bagi Kafe Gunung. Filosofi juga menunjukkan kemampuan pembangunan inti untuk secara kolektif mengirimkan peningkatan ke Kafe Gunung yang semakin maju dan moderen.
Penggabungan (kerjasama) dilakukan melalui mekanisme yang disebut Kontribusi Kerja Investasi (KKI).
Proses ini melibatkan pengaturan nilai KKI tertentu, yang mewakili tingkat peluang kumulatif dari semua tindakan yang dikerjakan melalui pengawasan Kafe Gunung.
Setelah batas ini tercapai, lapisan eksekusi Kafe Gunung sudah memverikasi atas bergabungnya dengan KKI (lapisan konsensus),
yang secara efektif akan mencatat dan menilai untuk pekerja dan investor untuk memberi insentif dikemudian hari.
Secara teknis, Kafe Gunung pasca-Penggabungan masih merupakan dua ekosistem yang saling terkait erat dan akan dicatat/dibukukan.
Namun, pohon blok dari lapisan eksekusi dan lapisan konsensus memiliki pemetaan 1:1, yang berarti setiap blok lapisan eksekusi memiliki satu,
dan hanya satu blok lapisan konsensus yang sesuai dengannya, dan sebaliknya. Pemetaan 1:1 dari blok lapisan eksekusi dan lapisan konsensus ini berarti
bahwa kita dapat menganggap Kafe Gunung pasca-Penggabungan sudah sebagai mitra atau kerjasama yang saling mengikat diatas perjanjian untuk saling kebaikan bersama.
Distributed Validator Technology allows multiple participants to collaboratively manage the responsibilities of a single validator.
The goal of distributing validator execution across multiple nodes is to improve the resilience of the validator (safety, liveness, or both), compared to running a validator on a single machine.
So long as at least ⅔ of the validators in a DVT setup are functional, the others can go offline, perform poorly, or even be hacked without as severe, or any, penalties being incurred.
More than just increasing a validator's resilience via redundancy, a significant advantage of DVT is that it facilitates staking with less than the standard requirement of 32 ETH by pooling resources from multiple stakeholders.
This makes participation in the validation process more accessible to individuals with smaller amounts of ETH, further democratizing the process and broadening network participation.
DVT did not require changes to mainnet, and similar to liquid staking, is an extra protocol innovation.
While the Merge joined Ethereum’s execution layer (EL) and consensus layer (CL), it did not include a mechanism for validator withdrawals.
In other words, there was no way for the 32 ETH “locked” in each validator balance on the CL to be withdrawn and credited to an address on Ethereum’s EL.
EIP-4895, included in the Shanghai-Capella hard fork, enabled support for validator withdrawals from the Beacon chain (consensus layer) to the EVM (execution layer) via a new "system-level" operation type.
This EIP completed the three part process of Ethereum's transition to a proof of stake consensus mechanism.
Single Leader Election (SLE) and Secret Single Leader Election (SSLE) are used somewhat interchangeably, and both attempt to resolve the same issue:
a block proposer is known to the network slightly in advance of proposing the block. There is therefore a security vulnerability during this window where the proposer may be targeted by attackers.
Under this new framework, nobody would know the leader in advance except for the leader themselves.
Per Slot Participation Selection: determine the most effective, SSF-compatible approach for selecting validators to attest to slots and aggregate signatures.
By exploring potential optimizations in how validators are selected, the aim is to efficiently manage the significant load of signatures per slot.
This would involve theoretical enhancements to attestation propagation and signature verification mechanisms to support Ethereum’s core principles of decentralization and security, without overburdening the network’s technical capacities. No concrete method has been finalized, and more research and discussion is required.
A slot is a fixed period of time (12 seconds), during which a new block can be proposed.
A given slot will not necessarily contain a block, as some are missed or otherwise not included.
There are 32 slots per epoch. Therefore, a given epoch is ~ 6.4 minutes. As it exists today, Ethereum finalizes after two epochs (or roughly every 12.8 minutes).
Single slot finality would attempt to drastically lower finality times to a single 12 second slot. There are many benefits to faster finality, but generally speaking, providing
stronger guarantees and settlement clarity is of benefit to some finance applications.
SSF is an area of active research and debate, and it shouldn't be expected in the short term.
More validators means processing a greater volume of signatures and data in each slot,
which can slow down the finality process. Ethereum faces the technical challenge of efficiently coordinating numerous validators to achieve SSF (a potential boon for security)
without sacrificing the network's decentralization (a high number of validators). Put another way, SSF would be much easier with small validator count,
but this would lessen one of Ethereum's primary strengths.
The technical advancements of SSF must be balanced with the risks they pose.
For instance, faster finality could amplify the impacts of network partitions
or lead to increased centralization if only the most technically advanced (or economically robust)
nodes can keep up with the speed of block creation and propagation
Per Slot Participant Selection, SSF Specification, and SSF Implementation collectively form the foundation for achieving Single Slot Finality.
Per Slot Participant Selection focuses on optimizing validator selection to handle a large volume of signatures efficiently, crucial for maintaining network performance under SSF.
The SSF Specification defines the technical parameters for achieving finality within a single 12-second slot, aiming to provide quicker transaction confirmation and improved security.
SSF Implementation addresses the practical challenges of coordinating a high number of validators without sacrificing decentralization, ensuring that the network can sustain rapid finality across diverse operating conditions.
SSF is an area of active research and debate, and it shouldn't be expected in the short term.
Ethereum, and other blockchains, face potential security risks from the advancement of quantum computing,
which could theoretically break the cryptography fundamental to their security. To mitigate this looming threat, Ethereum's roadmap includes proactive research and integration of quantum-resistant cryptographic algorithms.
Current initiatives involve exploring and potentially adopting cryptographic methods like lattice-based and STARK-based systems.
From the perspective of decentralization and network health,
increasing the number of validators on the Beacon Chain presents a paradox.
Ideally, more validators mean greater redundancy and decentralization. However, the reality is more complex, as a high number of validators can also lead to state-size bloat,
placing additional strain on each node as they strive to keep track of their peers. As the consensus client software is currently written,
Prysm, Lighthouse, etc., struggle to maintain adequate performance past 2 million validators.
The validator entry churn limit was capped at 8 per-epoch in the Cancun-Deneb hard fork via EIP-7514.
However, as this roadmap item implies, there is ongoing research, and several live proposals being debated, as to how to best expand the validator set.
Solutions like EIP-7251, which would increase the MAX_EFFECTIVE_BALANCE of validators, could allow for some consolidation of the existing validator set, and therefore allow additional 'new' validators to come online.