페이지를 넘기고 있습니다.
다음 장을 불러오고 있습니다…
잠깐… 나만의 읽기 환경을 만들어 보세요.
글꼴과 테마는 화면 설정에서 설정하세요. 눈의 편안함도 중요합니다.
다음 장을 불러오고 있습니다…
The need for a proof-of-stake node joining or returning after a long absence to obtain a sufficiently recent trusted checkpoint before validating forward.
브라우저의 읽어주기 지원을 확인하는 중…
이 읽기 자료는 현재 영어로 제공됩니다. 인터페이스에는 선택한 언어가 적용됩니다.
영어 원문 읽기 →Proof-of-stake systems can face long-range histories signed by parties whose former stake is no longer exposed to ordinary penalties. A new node cannot always distinguish the intended history solely by counting signatures from the distant past. Ethereum's weak-subjectivity model uses a recent checkpoint obtained through an external trust decision, after which the node checks subsequent blocks against protocol rules. This concerns establishing a starting point, not blindly accepting every later transaction.
Imagine an operator restarting a node after years offline and receiving two apparently signed historical chains from different peers. A sufficiently recent checkpoint narrows the acceptable history. The operator can compare checkpoints through independent, trusted channels before synchronizing forward. The exact permissible age depends on protocol conditions; it should not be replaced with an invented universal number of days. A checkpoint supplied by the same unknown peer as the history does little to diversify trust.
Weak subjectivity differs from the work-comparison rule associated with Bitcoin's design, but both systems have operational assumptions about connectivity and software validation. A checkpoint does not guarantee that a wallet interface is honest or that a smart contract is safe. It identifies the intended consensus history from which verification proceeds. Documentation should explain how checkpoints are obtained and updated, and avoid presenting the requirement either as proof of total centralization or as a detail with no security significance.