클라이언트

Zcash 재단은 트윗을 통해 Zebra 4.3.1 버전을 발표했다고 밝혔습니다. 이 버전은 여러 가지 중요한 보안 수정 사항을 포함하고 있으며, 모든 노드 운영자에게 즉시 업그레이드를 권장합니다. 또한, 이 버전은 Docker 기반 채굴 환경, 자동화된 체크포인트 관리 및 여러 CI 강화 개선 사항을 추가했습니다.

슬로우 후드 모니터링에 따르면, Apifox 데스크탑 클라이언트가 공급망 공격을 받았으며, 공식 CDN에서 호스팅되는 프론트엔드 스크립트 파일에 고도로 난독화된 악성 JavaScript 코드가 주입되었습니다.영향을 받은 사용자는 자격 증명 도용, 민감한 데이터 유출, 원격 명령 실행 등의 위험에 직면할 수 있으며, 악성 코드는 자동으로 실행되고 고도로 은폐되어 있습니다. 슬로우 후드는 사용자에게 모든 토큰을 즉시 철회하고, 비밀번호를 재설정하며, 세션을 무효화하기 위해 로그아웃 후 다시 로그인할 것을 권장하고, *.apifox.it.com 도메인을 차단하며, 로컬 저장소를 정리하고, API 로그 및 비정상 활동을 검토할 것을 권장합니다.

비탈릭은 X 플랫폼에서 글을 올리며, 이더리움의 현재 신호 체인과 실행 클라이언트 분리 아키텍처에 대해 열린 태도를 유지해야 한다고 언급했습니다. 그는 두 개의 데몬을 실행하고 서로 통신하게 하는 복잡성이 단일 데몬을 실행하는 것보다 명백히 높다고 생각합니다.비탈릭은 이더리움의 목표가 사용자가 자가 관리 방식으로 네트워크를 사용하고 좋은 사용자 경험을 얻는 것이라고 지적했습니다. 많은 경우 이는 사용자가 자신의 노드를 운영해야 함을 의미하지만, 현재 노드 운영 방식은 불필요한 복잡성을 증가시킵니다. 그는 단기적으로 더 표준화된 기본 포장 솔루션을 통해 사용자가 다양한 클라이언트의 Docker 이미지를 설치하고 더 편리한 통신을 할 수 있도록 할 수 있다고 제안했습니다. 동시에 LeanEthereum 합의 방식이 점차 성숙해짐에 따라, 미래에는 전체 아키텍처 디자인을 재검토하는 것도 고려해야 한다고 덧붙였습니다.

비트코인 클라이언트 Bitcoin Core의 개발 주요 분기가 Cluster Mempool 업데이트(PR #34616)를 병합하였으며, 이는 향후 Bitcoin Core 31 버전에 포함될 것으로 예상됩니다.이번 업그레이드는 노드가 처리 대기 중인 거래(mempool)를 관리하는 방식을 재설계하여 관련 거래를 그룹화 처리함으로써 블록 패킹 효율성을 높이고 RBF 및 CPFP 거래의 수수료 계산을 최적화합니다. Bitcoin Core 31은 2026년 하반기에 출시될 것으로 예상됩니다.

Neynar 공동 창립자 Rishav Mukherji가 Farcaster에 대한 비전을 설명하는 글을 발표했습니다: Neynar는 Farcaster 프로토콜을 유지하고, Farcaster 클라이언트를 운영하며, Clanker의 운영을 책임질 것입니다. 일부 Clanker 팀원들이 Neynar에 합류할 예정입니다. Neynar는 Farcaster 생태계의 중요한 인프라 제공자로서, 이번 통합은 수년간 커뮤니티에 깊이 참여한 후의 자연스러운 진화입니다.비전은 건설자가 아이디어에서 지속 가능한 수익으로 나아가도록 하여 "건설자 우선" 네트워크를 구축하는 것입니다. Farcaster의 핵심 가치는 장기적으로 형성된 건설자 커뮤니티에 있으며, 이 집단은 Frames, Degen, Warpcast 등 주요 혁신을 이끌어왔습니다. Farcaster의 가치는 제품에만 있는 것이 아니라, 실험하고 지식을 공유하며 공개적으로 구축하는 사람들에 있습니다. Neynar가 Farcaster를 인수한 핵심 임무는 소프트웨어 구축을 더 쉽게 만드는 것입니다.제품 측면에서 Farcaster, Neynar 또는 Clanker에 대한 중대한 조정은 없을 것이며, 프로토콜이나 클라이언트 중단에 대한 소문은 사실이 아닙니다. Neynar 개발자 플랫폼은 계속 존재하며, 금융 및 거래 관련 기능도 현 상태를 유지할 것입니다. 다음 단계는 제품 우선순위를 중심으로 평가를 진행하며, 네트워크의 개방성을 유지하는 동시에 점진적으로 로드맵을 추진할 것입니다. 소프트웨어 구축의 진입 장벽이 지속적으로 낮아짐에 따라, 암호화 원주 금융 경로와 개방형 배포 메커니즘을 결합하여 Farcaster는 창작자와 개발자가 실험하고 협력하며 규모화로 나아가는 중요한 출발점이 될 것으로 기대됩니다.

Prysm 팀은 주 네트워크 사고 복구 보고서를 발표하며, 12월 4일 이더리움 주 네트워크 Fusaka 시간대 내에 거의 모든 Prysm 신뢰 노드가 특정 attestations를 처리하는 과정에서 자원 고갈이 발생하여 검증자 요청에 즉시 응답할 수 없었고, 이로 인해 블록과 증인이 대량으로 누락되었다고 전했습니다.사고의 영향 범위는 epoch 411439부터 411480까지로, 총 42개의 epoch에서 1344개의 슬롯 중 248개의 블록이 누락되어 누락률은 약 18.5%에 달했습니다. 네트워크 참여율은 한때 75%로 떨어졌으며, 검증자는 약 382 ETH의 증인 보상을 잃었습니다. 근본 원인은 Prysm이 주 네트워크와 동기화되지 않은 노드로부터 attestations를 수신했기 때문이며, 이 attestations는 이전 epoch의 블록 루트를 참조하고 있습니다.합법성을 검증하기 위해 Prysm은 이전 epoch 상태를 반복 재생하고 높은 비용의 epoch 전환을 수행하여 노드가 높은 동시성 하에서 자원 고갈을 유발했습니다. 관련 결함은 Prysm PR 15965에서 발생했으며, 이는 한 달 전 테스트 네트워크에 배포되었지만 동일한 상황을 유발하지는 않았습니다.공식적으로 제시된 임시 해결책은 v7.0 버전에서 --disable-last-epoch-target 매개변수를 활성화하는 것이며, 이후 발표된 v7.1 및 v7.1.0에는 장기 수정 방안이 포함되어 있습니다. 이는 head state를 사용하여 attestations를 검증함으로써 역사적 상태의 반복 재생을 피하는 것입니다.Prysm은 문제는 12월 4일 UTC 4:45 이후 점차 완화되었으며, epoch 411480 시점에서 네트워크 참여율이 95% 이상으로 회복되었다고 밝혔습니다.Prysm 팀은 이번 사건이 클라이언트 다양성의 중요성을 강조한다고 지적했습니다. 만약 단일 클라이언트의 비율이 3분의 1을 초과하면 일시적으로 종료할 수 없게 될 수 있으며, 3분의 2를 초과할 경우 종료 무효 체인의 위험이 존재합니다. 또한 기능 스위치의 소통 부족과 테스트 환경이 대규모 비동기 노드를 시뮬레이션하지 못한 문제를 반성하며, 향후 테스트 전략 및 구성 관리를 개선할 것이라고 밝혔습니다.

Jump Crypto 개발의 Solana 독립 검증 클라이언트 Firedancer가 3년의 개발 끝에 Solana 메인넷에 공식 출시되었으며, 몇 개의 검증 노드에서 안정적으로 100일 동안 운영되어 50,000개의 블록을 성공적으로 생성했다고 발표했습니다.

Cointelegraph 모니터링에 따르면, Fusaka 네트워크 업그레이드 직후 Prysm 합의 클라이언트의 버그로 인해 Ethereum 네트워크의 검증자 참여도가 급격히 감소하고 많은 투표 노드가 오프라인 상태가 되었습니다.Prysm 공식은 목요일에 v7.0 버전 클라이언트가 구식의 Attestations(증명)를 처리할 때 불필요하게 이전 상태를 생성하여 노드가 정상적으로 작동하지 못하게 했다고 발표했습니다. 개발자들은 사용자에게 클라이언트를 임시 해결책으로 시작하기 위해 "--disable-last-epoch-targets" 플래그를 사용할 것을 권장했습니다.Beaconcha.in 데이터에 따르면, Epoch 411,448에서 네트워크의 동기화 참여도(Sync Participation)와 투표 참여도(Voting Participation)는 각각 75%와 74.7%로 감소했습니다. 투표 참여도는 25% 감소했으며, 네트워크가 최종 확정을 유지하는 데 필요한 3분의 2 다수(66.6%)의 슈퍼 다수와는 9% 포인트 미만의 차이가 있습니다.이번 투표 참여도의 감소폭은 Prysm 합의 클라이언트의 검증자 점유율과 대체로 일치하며, Attestation 실패가 Prysm 검증자에 집중될 가능성이 높음을 나타냅니다. 이전에 Prysm의 점유율은 한때 68.1%에 달했습니다. 기사를 작성할 당시 Ethereum 네트워크의 현재 Epoch(411,712) 투표 참여도는 99%에 가까워졌고, 동기화 참여도는 97%에 달하여 네트워크가 복구되었음을 나타냅니다.현재 MigaLabs 데이터에 따르면, Lighthouse는 여전히 합의 노드의 52.55%를 차지하고 있으며, Prysm은 18%로 두 번째를 차지하고 있습니다. Ethereum 교육자 Anthony Sassano는 Lighthouse가 이 버그를 겪었다면 네트워크가 최종 확정을 잃었을 것이라고 말했습니다.

이더리움 클라이언트 Prysm은 문제의 원인을 파악했으며, 빠른 임시 해결책을 제시했습니다. 모든 노드는 Prysm에서 불필요하게 생성된 이전 상태를 비활성화하여 만료된 증명을 처리해야 합니다. 신호 노드에 "--disable-last-epoch-targets" 플래그를 추가하기만 하면 됩니다. 이 매개변수는 v7.0 버전에 적용되므로 신호 노드를 추가로 업그레이드할 필요 없이 해당 매개변수만 추가하면 됩니다. 검증자 클라이언트는 아무런 변경을 할 필요가 없습니다.

Lido 공식 발표에 따르면, 이더리움 Fusaka 하드 포크가 순조롭게 완료된 후, Prysm 합의 계층 클라이언트에서 취약점이 발생하여 네트워크 참여도에 문제가 생겼습니다. Lido 프로토콜은 정상적으로 운영되고 있으며, 스테이커들은 걱정할 필요가 없습니다.프로토콜의 기본 검증 노드 집합이 분산되고 탈중앙화된 특성 덕분에 Lido는 이 사건의 영향을 적게 받았으며, Prysm 클라이언트 팀과 노드 운영자의 신속한 대응이 문제 완화에 도움이 되었습니다. Lido 팀은 Prysm 팀과 긴밀히 협력하여 야간에 사건 진행 상황을 모니터링하고, 영향을 받은 노드 운영자들이 권장된 임시 해결책을 취할 수 있도록 도왔습니다. 현재 대부분의 Lido에서 운영되는 Prysm 설정이 복구되었으며, 일부 노드는 임시로 다른 클라이언트 구성으로 전환하여 수리를 완료했습니다.

이더리움 재단은 X 플랫폼에서 메인넷의 Prysm 합의 클라이언트에 현재 문제가 있다고 밝혔습니다. Prysm을 사용 중인 경우 CL 노드를 재구성해야 합니다. 다른 클라이언트를 사용 중인 경우에는 영향을 받지 않으며, 아무런 조치를 취할 필요가 없습니다.이전 소식에 따르면, 이더리움 메인넷은 Fusaka 업그레이드를 성공적으로 활성화하여 데이터 처리 능력을 크게 향상시켰습니다.

ChainCatcher 메시지, 이더리움 클라이언트 Nimbus가 트위터에서 v25.9.1 버전이 출시되었다고 발표했습니다. 이 버전은 메인넷에서 낮은 긴급 수준이지만, Hoodi, Sepolia, Holesky 테스트넷에서는 높은 긴급 수준입니다. 그 이유는 위의 네트워크가 곧 Fusaka 분기를 진행할 예정이기 때문입니다. 팀은 관련 테스트넷 노드가 분기에 맞게 신속하게 업그레이드할 것을 권장합니다.

ChainCatcher 메시지에 따르면, 시장 소식에 의하면 Paradigm의 최고 기술 책임자 Georgios Konstantopoulos가 이더리움 실행 레이어 클라이언트 Reth에서 블록 2327426에서 취약점이 발생하여 해당 클라이언트에 의존하는 노드가 중단되었다고 밝혔습니다. 영향을 받은 버전은 Reth 1.6.0과 1.4.8입니다. Paradigm은 GitHub 페이지에 노드를 복구하는 지침을 게시했지만, 취약점의 근본 원인은 여전히 조사 중입니다.Reth는 Paradigm이 개발한 이더리움 실행 레이어 클라이언트로, Rust 언어로 작성되어 성능과 모듈화를 향상시키기 위해 설계되었습니다. 현재 데이터에 따르면 Reth는 이더리움 실행 레이어 클라이언트 총량의 5.4%만 차지하고 있어 이번 취약점의 영향 범위는 제한적입니다. 실행 레이어 클라이언트는 거래 및 상태 업데이트를 처리하고 상태 루트를 계산하여 블록체인의 글로벌 상태의 무결성을 보장합니다. 이번 취약점은 일부 노드가 블록을 검증하고 네트워크와 동기화할 수 없게 만들 수 있습니다.

ChainCatcher 메시지, Synthetix 창립자 kain.avax가 X 플랫폼에 글을 올리며, 그는 Cursor를 사용하여 개발 환경을 구축하고 새로운 클라이언트 프로젝트를 설계했으며, 이후 서버/데이터베이스를 추가하여 해당 프로젝트를 더욱 견고하게 만들 것이라고 밝혔습니다. Claude Opus는 1만 줄의 코드가 포함된 Pull Request를 제출했으며, 그는 전체 프로젝트를 재구성하는 데 40분을 소요했습니다. 현재 해당 프로젝트는 거의 작동할 수 있는 상태입니다.이전에 Synthetix가 출시한 스테이블코인 sUSD가 탈피했으며, 현재 SCCP-409 제안이 승인되어 sUSD의 고정에 추가 지원을 제공합니다. 채무 면제(jubilee) 참여자의 sUSD 스테이킹 요구 사항이 10%에서 20%로 증가하여 sUSD의 고정을 회복하는 데 기여하고 있습니다.

ChainCatcher 메시지에 따르면, Tim Beiko가 정리한 제 209회 이더리움 실행 레이어 핵심 개발자 회의(ACDE)에서는 다가오는 Pectra와 Fusaka 업그레이드에 대해 중점적으로 논의되었습니다. Pectra 클라이언트는 4월 21일에 출시될 예정이며, EIP-7702 위임 상태를 JSON-RPC에 추가합니다. Fusaka 측에서는 EIP-7823(모드 복잡도 제한), EIP-7825(거래 가스 한도) 및 EIP-7907(계약 코드 크기 측정 및 제한 증가)를 명확히 포함할 것입니다; EIP-7762와 EIP-7918은 blob 비용 메커니즘에서 하나를 선택하여 자원 활용과 시장 수요 공급의 균형을 맞출 것입니다.

ChainCatcher 메시지에 따르면, Tim Beiko가 요약한 제 209회 이더리움 실행 레이어 핵심 개발자 회의(ACDE)에서는 다가오는 Pectra와 Fusaka 업그레이드에 대해 중점적으로 논의했습니다. Pectra 클라이언트는 4월 21일에 출시될 예정이며, EIP-7702 위임 상태를 JSON-RPC에 추가합니다.Fusaka 측에서는 EIP-7823(모드 복잡도 제한), EIP-7825(거래 가스 한도) 및 EIP-7907(계약 코드 크기 측정 및 제한 증가)를 명확히 포함할 예정입니다; EIP-7762와 EIP-7918은 blob 비용 메커니즘에서 하나를 선택하여 자원 활용과 시장 수요 공급의 균형을 맞출 것입니다.

ChainCatcher 메시지에 따르면, 이더리움 클라이언트 Nethermind의 책임자인 Marek Moraczyński가 X 플랫폼에 게시한 내용에 따르면, 80% 이상의 이더리움 전체 노드 디스크 공간이 역사 기록에 의해 차지되고 있어, 새로운 블록을 검증하는 데 데이터가 필요하지 않다고 합니다. 새로운 버전 1.3.1에서 Nethermind는 ERA 파일을 통해 병합 이전의 역사 기록을 삭제할 준비가 되어 있으며, 모든 팀은 5월 1일에 관련 작업을 수행하기로 동의했습니다. 모든 블록과 모든 영수증을 삭제하고 최신 블록을 검증하는 데 필요한 데이터만 유지하면, 전체 노드 용량은 200GB 미만이 될 것입니다.

ChainCatcher 메시지, 이더리움 재단이 공식 블로그에 게시한 바에 따르면, Pectra 네트워크 업그레이드는 이전에 Sepolia 테스트넷에서 출시되었으나, 이후 Sepolia의 허가된 예치 계약에 문제가 발견되어 많은 실행 계층 클라이언트가 거래를 블록에 포함할 수 없게 되었습니다. 문제의 원인은 빠르게 확인되었으며, 클라이언트 팀은 즉시 수리를 시작했습니다. 이 문제는 Sepolia의 테스트넷 구성에 특정적이며, 이더리움 메인넷에서는 발생할 수 없습니다. 현재 검증자는 수정 프로그램을 배포하여 네트워크를 정상 처리량으로 복구했습니다. 모든 Sepolia 노드 운영자는 이제 네트워크 호환성을 유지하기 위해 실행 계층 클라이언트를 업그레이드해야 합니다.