Solana v1.17 업데이트의 모든 것
이 글에서는 무엇을 다루나요?
Solana 네트워크는 Solana Labs 검증인 클라이언트의 최신 버전인 1.17을 압도적 다수가 도입하며 중요한 이정표를 달성했습니다. 최근 네트워크 중단 이후 검증인들은 버전 1.17.20으로 재시작했습니다. 이 글을 작성하는 시점에 검증인의 ~68.6%는 버전 1.17.21을, ~31.3%는 버전 1.17.20을 실행하고 있습니다. 새 버전에는 네트워크의 효율성, 확장성, 활용 사례를 강화하기 위한 다양한 개선 사항이 포함됩니다. 영지식 증명의 선도적인 발전부터 Gossip 프로토콜 개선까지, v1.17은 Solana의 지속적인 발전에서 중요한 전환점입니다.
이 글에서는 Solana Labs 검증인 클라이언트 버전 1.17 업데이트에 관해 알아야 할 모든 내용을 다룹니다. v1.17에 적용된 엄격한 테스트, 최근 네트워크 중단, 이번 업데이트로 구현된 새로운 기능을 살펴보겠습니다.
v1.17은 어떻게 테스트되었나요?
v1.17은 2023년 10월 3일부터 테스트넷에서 실행되었습니다. 높은 트랜잭션 부하를 적용한 스트레스 테스트도 정기적으로 진행했습니다. Solana Labs는 실제 환경에서 버전의 안정성을 모니터링하기 위해 v1.17을 실행하는 메인넷 베타 카나리 노드도 일부 배포했습니다. 이 노드들은 지난 몇 달 동안 안정적으로 운영되었습니다. 카나리 노드의 이전 활동과 진행 상황은 Solana Tech Discord의 #canaries-monitoring 채널에서 확인할 수 있습니다. 또한 2023년 12월 4일부터 일부 자원봉사 메인넷 베타 노드가 v1.17로 업그레이드했습니다.
경계 사례나 드물게 발생하는 경쟁 조건을 포착하기 위해 부분적으로 무작위화된 트랜잭션을 실행하는 여러 런타임 퍼저를 개발했습니다. 일관된 성능을 보장하기 위해 여러 버전에서 이 트랜잭션들을 실행했습니다. v1.17은 외부 감사 기관의 감사를 여러 차례 받았으며, 결과는 준비되는 대로 Solana Security Audits GitHub 저장소에 게시됩니다.
2월 네트워크 중단
2024년 2월 6일 9시 53분(UTC), 메인넷 베타에서 블록 확정이 일시적으로 중단되는 장애가 발생했습니다. 14시 55분(UTC)에 합의가 재개될 때까지 약 5시간 동안 네트워크 활동이 중단되었습니다. 이 장애는 네트워크가 실행할 프로그램 코드를 컴파일하고 캐싱하는 방식과 관련된 버그에서 비롯되었으며, 특히 이전 버전의 프로그램 로더에 영향을 미쳤습니다.
근본 원인은 검증인이 자주 사용하는 프로그램의 Just-in-time(JIT) 컴파일 결과를 처리하는 방식에 있었습니다. 이 프로세스를 최적화하기 위해 도입한 새로운 캐싱 시스템에 치명적인 버그가 의도치 않게 포함되었습니다. 특정 레거시 프로그램에서 새 시스템이 무한 재컴파일 루프에 진입할 수 있었습니다. 대다수 검증인이 이 문제를 겪어 트랜잭션 처리를 계속할 수 없게 되면서 Solana의 합의 메커니즘이 멈췄습니다.
이 버그는 최근 개발넷 중단과 여러 면에서 유사했기 때문에 근본 원인을 빠르게 파악했습니다. 문제를 직접 해결하도록 1.17.20을 수정했고, 검증인들은 네트워크 재시작을 조율했습니다. 수정은 두 부분으로 이루어졌습니다. 단기적으로는 무한 루프를 유발할 수 있는 레거시 로더 2개를 폐기해 루프가 시작되지 않도록 했습니다. 장기적으로는 향후 유사한 문제를 방지하도록 새로운 프로그램 캐싱 시스템을 전반적으로 조정했습니다.
ZK Token Proof Program
ZK Token Proof Program은 1.16 업데이트와 함께 출시될 예정이었습니다. 하지만 광범위한 감사로 인해 활성화가 지연되었습니다. Feature Gate Activation Schedule에는 이 프로그램이 최소 버전 1.17.12에서 테스트넷 활성화 대기 중으로 표시되어 있습니다.
기밀 전송
ZK Token Proof Program이 활성화되면 마침내 기밀 전송을 사용할 수 있습니다. 기밀 전송은 영지식 증명을 사용해 SPL 토큰의 잔액과 전송 금액을 암호화합니다. 전반적인 목표는 익명성이 아니라 기밀성입니다. 동형 암호화를 사용하면 암호화된 데이터를 복호화하지 않고도 연산할 수 있습니다. 예를 들어 해당 금액을 복호화하고 다시 암호화하지 않아도 잔액을 더하거나 뺄 수 있습니다. 따라서 이러한 연산은 평문에 적용했을 때와 동일한 방식으로 암호화된 상태에서 수행됩니다.
기밀 전송은 Twisted ElGamal Encryption과 Sigma Protocols를 사용해 민감한 정보를 공개하지 않고 안전한 비공개 트랜잭션을 지원합니다.
참고로 다음과 같습니다.
- Twisted ElGamal Encryption은 표준 ElGamal 암호화 체계의 단순한 변형입니다. 암호문을 암호화된 메시지의 Pedersen commitment와 복호화 핸들로 나눠 암호문에 숨겨진 수학 연산을 수행할 수 있게 합니다.
- Sigma Protocols는 기밀 전송을 검증하는 데 사용됩니다. 한 당사자(즉, 증명자)가 특정 정보를 공개하지 않고도 그 정보를 알고 있음을 다른 당사자(즉, 검증자)에게 증명할 수 있는 특수한 영지식 증명 유형입니다.
기밀 전송에서는 복호화 키를 보유한 계정만 암호화된 잔액을 볼 수 있습니다. 제3자의 검토가 필요한 상황(예: 규정 준수 검사 또는 감사)을 위해 Global Auditor System이 구현되어 있습니다. 이 시스템을 통해 계정 보유자는 별도의 복호화 키로 특정 계정에 선택적 읽기 권한을 부여할 수 있습니다. 또한 안전한 감사를 지원하도록 민트에 “감사자 암호화 키”를 포함합니다.
트랜잭션은 개인정보 보호와 무결성을 보장하기 위해 증명과 함께 발신자, 수신자, 감사자 금액에 암호화된 매개변수를 사용합니다. 프런트 러닝 공격을 방지하기 위해 계정 잔액은 “대기 중”과 “사용 가능”으로 나뉩니다. 이렇게 하지 않으면 악의적인 사용자가 계정에 토큰을 전송해 암호화된 잔액으로 생성한 증명을 무효화할 수 있습니다.
기밀 전송에는 새로운 키 쌍을 사용해야 한다는 점에 유의하세요.
명령줄 지원
spl-token 크레이트를 통한 기밀 전송용 명령줄 인터페이스(CLI) 지원도 제공됩니다. 활성화 후 create-token 명령에 –enable-confidential-transfers auto 플래그가 추가됩니다. 이를 통해 기밀 전송 확장이 활성화된 토큰을 발행할 수 있습니다. 다음과 같은 여러 유용한 명령도 있습니다.
configure-confidential-transfer-account- 기존 계정에 기밀 전송을 구성합니다. 계정 소유자만 해당 계정에 기밀 전송을 구성할 수 있습니다.deposit-confidential-tokens- 비기밀 계정에서 기밀 계정으로 토큰을 입금합니다. 입금된 토큰은 기밀 잔액으로 완전히 이동하므로 계정의 비기밀 잔액에는 더 이상 존재하지 않습니다.apply-pending-balance- 잔액을 “대기 중”에서 “사용 가능”으로 이동합니다. 계정이 전송 또는 입금으로 기밀 토큰을 받으면 계정의 “대기 중” 잔액에 표시되므로 이 작업이 필요합니다. 따라서 사용자는 자금에 즉시 접근할 수 없으며 대기 중 잔액을 적용해야 합니다.transfer(–confidential플래그 활성화) - 기밀 전송이 구성된 다른 계정으로 토큰을 전송합니다. 이 작업에는 서로 의존하는 여러 트랜잭션이 필요하므로 일반 토큰 전송보다 오래 걸릴 수 있습니다.withdraw-confidential-tokens- 계정의 기밀 잔액에서 비기밀 잔액으로 토큰을 출금합니다. 예상한 토큰을 모두 출금하려면 이 명령을 실행하기 전에 대기 중 잔액이 적용되었는지 확인하세요.update-confidential-transfer-settings- 지정된 토큰 민트의 기밀 전송 구성을 업데이트합니다. 기밀 전송 승인 정책을 자동으로 설정하는 옵션(즉,–aprove-policy플래그)과 감사자의 공개 키를 설정하는 옵션(즉,–auditor-pubkey플래그)을 제공합니다. 블록 해시, 기밀 전송 권한, 구성 파일, 수수료 지불자 세부 정보, JSON RPC URL, 논스 계정 세부 정보, 출력 형식, 토큰 프로그램 ID를 지정하는 추가 플래그도 제공합니다.
호환성
다음 확장 조합은 작동하지 않거나 기밀 전송과 함께 사용할 실익이 없습니다.
- 기밀 전송 + 전송 불가
- 기밀 전송 + 수수료(1.18까지 작동하지 않음)
- 기밀 전송 + Transfer Hooks(이 전송은 소스 또는 대상 계정만 볼 수 있어 전송 금액에 따라 동작할 수 없기 때문)
감사
기밀 전송과 전반적인 Token-2022 Program은 Halborn, Zellic, Trail of Bits, NCC Group, OtterSec 등의 업체로부터 광범위한 감사를 받았습니다. OtterSec은 두 차례 감사를 진행했으며, 첫 번째 감사는 Token-2022에, 두 번째 감사는 기밀 전송에 중점을 두었습니다.
Poseidon 시스템 호출
Poseidon은 영지식 증명에 적합한 해시 함수 계열입니다. Poseidon 해시 함수는 Zcash, Mina, Solana의 Light Protocol을 비롯한 대부분의 ZK 기반 블록체인 프로젝트에서 사용합니다. 현재 Solana에서 Poseidon 해시를 계산하는 비용은 너무 높아 하나의 트랜잭션에서 처리할 수 없습니다. Poseidon 시스템 호출이 이를 바꿀 전망입니다. 현재 v1.17.5에서 출시될 예정이며 테스트넷 활성화를 기다리고 있습니다.
쉬운 설명
안전한 통신에 쓰이는 특정 유형의 퍼즐을 효율적으로 푸는 고급 계산기를 떠올려 보세요. 이 계산기는 여러 정보 조각을 받아 잘게 나누고 고유한 방식으로 혼합합니다. 원본 내용은 완전히 숨겨지지만 검증은 가능하도록 정보를 섞습니다.
이 혼합 과정에서는 미리 정해진 특정 숫자 집합에 속하는 수를 더하고 특정 지수로 거듭제곱하는 특별한 방법을 사용합니다. 이 방법을 통해 매번 철저하고 일관되게 혼합할 수 있습니다.
Poseidon은 이 고급 계산기와 정확히 같은 작업을 합니다. 이러한 유형의 해시 함수는 영지식 회로를 만드는 데 매우 적합합니다. 회로는 본질적으로 수학 연산의 모음입니다. 한 당사자(증명자)가 특정 정보를 공개하지 않고도 그 정보를 알고 있음을 다른 당사자(검증자)에게 증명하는 과정을 수학적으로 나타냅니다. 일반적으로는 봉인된 상자를 실제로 열지 않고도 안에 무엇이 있는지 알고 있음을 증명하는 것이라고 생각하면 됩니다. 일련의 두드림이나 단계를 통해 상자를 봉인한 사람에게 이를 증명할 수 있습니다. 이러한 두드림이나 단계는 상자 안의 내용이나 상자를 여는 방법에 관한 어떤 세부 정보도 노출하지 않으며, 상자를 열어 본 사람만 이해할 수 있도록 설계됩니다.
진위를 검증하면서도 트랜잭션을 비공개로 유지하는 것은 매우 중요하므로 블록체인에 유용합니다.
ZK 친화적 특성
Poseidon 해시 함수가 영지식에 친화적인 것으로 평가되는 데에는 몇 가지 이유가 있습니다. 구체적으로 다음과 같습니다.
- Poseidon은 영지식 증명 계산에서 일반적으로 사용하는 산술 연산(즉, 덧셈, 곱셈, 거듭제곱)을 효율적으로 수행하도록 설계되었습니다.
- 영지식 증명 시스템은 계산 로직을 암호학적 증명으로 변환해야 합니다. Poseidon은 산술 친화적 설계, 최적화된 S-box, 맞춤 설정 가능한 매개변수, 적은 라운드 수(즉, 입력 데이터 또는 해시 함수의 내부 상태에 반복적으로 적용되는 일련의 연산) 덕분에 다른 해시 함수보다 회로 복잡도가 낮습니다. 즉, 주어진 데이터의 증명을 생성하는 데 필요한 단계가 더 적습니다.
- Poseidon 해시 함수는 스펀지 구조를 기반으로 합니다. 즉, Poseidon은 길이에 상관없이 비트 시퀀스를 입력받아 임의 길이의 출력을 생성하는 알고리즘 계열을 사용해 설계되었습니다. 따라서 Poseidon 해시 함수를 다양한 영지식 애플리케이션에 매우 쉽게 통합할 수 있습니다.
기존 해시 함수와의 비교
영지식 증명에 최적화된 Poseidon의 계산 효율성은 SHA-256 같은 기존 범용 해시 함수의 계산 집약적 연산보다 뚜렷한 이점을 제공합니다.
기존 해시 함수는 안전하고 신뢰할 수 있지만, 영지식 증명 내부에서 더 크고 복잡한 회로를 만드는 경우가 많습니다. 원래 영지식 증명 시스템의 구체적인 제약을 고려해 설계되지 않았기 때문입니다. 블록체인에서 영지식 증명은 유한체 내에서 계산을 수행합니다. 유한체는 모든 산술 연산(덧셈, 뺄셈, 곱셈, 나눗셈)을 소수로 모듈로 연산하는 숫자 집합입니다. 이에 따라 값이 집합 안에서 순환하며 모든 연산 결과가 이 숫자 집합 안에 유지됩니다.
SHA-256 같은 기존 해시 함수는 비트 연산과 미리 정해진 연산 순서에 크게 의존합니다. 이러한 기능은 유한체에서 사용하는 산술 연산과 직접 호환되지 않습니다. 유한체의 맥락에서 이러한 연산을 구현하려면 추가 단계가 필요해 결국 회로의 복잡도가 높아집니다.
또한 기존 해시 함수는 일반적으로 2의 거듭제곱을 기반으로 하는 모듈러 산술을 사용합니다. 이는 주로 소수를 기반으로 하는 영지식 증명의 유한체 모듈러 산술과 다릅니다. 이 비호환성을 해결하려면 더 많은 단계가 필요해 회로의 크기와 복잡도가 증가합니다.
영지식 증명 구축의 목표는 특정 정보를 공개하지 않고도 해당 정보를 알고 있음을 증명하는 계산 로직의 수학적 표현을 만드는 것입니다. 이 지식을 효율적이고 단순하게 표현하는 것은 증명의 확장성에 매우 중요합니다. Poseidon 계열 해시 함수는 유한체 내에서 효율적인 연산을 사용해 이러한 요구를 직접 해결하고, 회로 생성에 필요한 단계를 크게 줄입니다. 그 결과 더 작고 단순한 회로를 만들 수 있습니다. 기존 해시 함수는 회로 구축 요구를 직접 해결하도록 최적화되지 않았으며, 범용으로 설계되었습니다.
v1.17에 Poseidon 시스템 호출을 통합한 것은 Solana에서 영지식 증명을 간소하게 생성하고 검증하기 위해 특수 암호화 도구를 사용하는 방향으로 전환했음을 뜻합니다. 그 결과 트랜잭션 처리 속도가 빨라지고 비용은 줄며 영지식 계산의 확장성이 향상됩니다. Poseidon의 유연성과 맞춤 설정 가능성까지 더해져 Solana에서 영지식 증명을 생성하고 검증하기가 훨씬 쉬워졌습니다.
구체적인 구현
v1.17에는 sol_poseidon 시스템 호출이 도입됩니다. 2차원 바이트 슬라이스를 입력받아 해당 Poseidon 해시를 출력으로 계산하는 시스템 호출입니다. BN254 곡선을 사용하며 다음 Poseidon 매개변수를 입력받습니다.
- x^5 S-boxes(즉, 치환 상자)
- 1 ≤ n ≤ 12인 입력
- 2 ≤ t ≤ 13인 너비
- 8개의 전체 라운드와 t에 따른 부분 라운드: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]
이러한 Poseidon 해시는 감사를 받았으며 Circom과 호환되는 light-posiedon 크레이트로 계산합니다.
다음 섹션에서는 alt_bn128 시스템 호출의 추가를 설명합니다. BN254는 구어적으로 보안 비트 수를 따서 BN128이라고 하며 alt_bn128 또는 alt_bn_128이라고도 합니다. 여기서는 모두 같은 곡선을 지칭합니다.
alt_bn128 시스템 호출
v1.16에서는 영지식 계산, 특히 128비트 타원 곡선 연산에 대한 향상된 런타임 지원을 제안했습니다. 증명을 효율적으로 생성하는 데 중요한 alt_bn128 시스템 호출은 v1.16과 함께 출시될 예정이었습니다. 하지만 출시가 지연되었습니다. 현재 Feature Gate Activation Schedule에 따르면 alt_bn128 시스템 호출은 v1.17.15에서 메인넷 베타 활성화를 기다리고 있으며, alt_bn128 압축은 v1.17.15에서 테스트넷 활성화를 기다리고 있습니다.
더 자세히 알고 싶은 분을 위해 설명하면, alt_bn128은 Barreto-Naehrig(BN-128) 타원 곡선의 구현을 가리킵니다. 효율적인 zk-SNARK(Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)를 지원하는 특정 페어링 친화적 타원 곡선입니다. 특정 영지식 계산과 증명을 더 효율적으로 수행할 수 있어 “페어링 친화적”이라고 합니다. Solana에서 alt_bn128 시스템 호출을 사용하면 프로그램이 이 곡선을 활용해 영지식 증명을 간소하게 검증하고 보안과 개인정보 보호를 강화할 수 있습니다. alt_bn128 g1 및 g2 시스템 호출을 추가하면 Groth16 증명 압축을 지원하는 데 도움이 됩니다. 증명당 필요한 공간을 크게 줄여 Solana 프로그램의 공간 효율성을 높입니다.
alt_bn128 시스템 호출을 도입하면 Solana와 EIP-196, EIP-197, EIP-198에 명시된 타원 곡선 연산용 사전 컴파일 계약에 의존하는 Solidity 기반 계약 간의 호환성 격차를 줄일 수 있습니다. 이러한 연산(bn256Add, bn256ScalarMult, bn256Pairing)은 Ethereum의 가스 한도 내에서 zk-SNARK 검증을 지원합니다. 이 타원 곡선 연산에 의존하는 Solidity 계약은 이제 Solana로 더 쉽게 이전하거나 Solana와 상호 운용할 수 있습니다.
Gossip 개선
v1.17은 푸시 메시지 전파를 강화하고 풀 요청 의존도를 줄여 Gossip 메시지 전파 효율을 개선합니다. Gossip 프로토콜의 작업을 간소화하면 합의 검증인의 리소스 사용량을 줄이는 데 도움이 됩니다.
참고로 Solana의 Gossip Service는 검증인 간 정보 교환에 필수적입니다. 원장 높이, 연락처 정보, 합의 투표 등의 정보를 교환합니다. 네트워크 전반에서 정보를 공유하고 검증하기 위해 “푸시” 및 “풀” 메시지를 사용합니다. 이 메시징 시스템은 모든 노드가 동기화된 상태를 유지하도록 합니다.
기존에는 AccountsHashVerifier가 계정 해시를 Gossip에 푸시했습니다. 하지만 어떤 네트워크 구성 요소도 이 데이터를 가져오지 않아 이 프로세스는 불필요했습니다. Gossip의 계정 해시를 알려진 검증인의 값과 비교하는 등의 기존 작업은 EpochAccountsHash의 도입과 함께 제거되었습니다. getHealth RPC 메서드도 더 이상 Gossip의 계정 해시에 의존하지 않도록 다시 작성되었습니다. 다음 섹션에서 자세히 살펴보겠습니다. 따라서 v1.17부터는 어떤 구성 요소도 Gossip에서 계정 해시를 가져오지 않습니다. AccountsHashVerifier는 계정을 Gossip에 푸시하지 않도록 수정되었고, Gossip에서 계정 해시를 푸시하고 가져오던 함수도 제거되었습니다.
getHealth
이전에는 getHealth RPC 호출이 특정 노드의 잘못된 상태를 나타낼 수 있었습니다. solana catchup CLI 명령과 getHealth RPC 호출 간의 불일치로 인해 노드가 동기화된 동시에 뒤처진 것으로 표시될 수 있었기 때문입니다. 이로 인해 정상 노드가 비정상으로 잘못 표시되어 RPC 풀에서 제거될 가능성이 있었습니다.
원래 상태는 Gossip에 게시된 로컬 계정 해시 슬롯을 다른 노드의 값과 비교해 판단했으며, 기본 비교 값은 100슬롯이었습니다. 이는 특히 100슬롯보다 큰 값으로 구성된 노드에서 부정확할 수 있었습니다. getHealth은 클러스터에서 낙관적으로 확인된 최신 슬롯을 사용하도록 다시 작성되었습니다. 이는 모든 검증인이 처리하고 압도적 다수가 확인했지만 아직 확정되지는 않은 마지막 슬롯입니다. 클러스터 확인 슬롯과 낙관적으로 확인된 최신 뱅크를 비교해 노드가 얼마나 뒤처졌는지 판단할 수 있으므로 더 정확합니다. 이 변경으로 더 세밀한 검사가 가능해지고, 오탐(즉, 정상 노드가 비정상으로 표시되는 경우)이 발생할 가능성이 줄어듭니다. 또한 알려진 검증인에 영향을 미치는 문제가 연쇄 효과를 일으키지 않도록 보호합니다.
getHealth 관련 문제를 해결하기 위해 wait-for-restart-window 및 exit 명령에 –skip-health-check 플래그도 추가되었습니다. 이를 사용하면 검증인이 노드의 정상 여부 검사를 건너뛸 수 있습니다.
QUIC
v1.17에서는 QUIC을 사용해 샤드를 브로드캐스트하고 복구할 수 있습니다. Turbine 및 복구 QUIC 엔드포인트는 테스트넷이 QUIC으로 완전히 마이그레이션되기 전까지 필요하지 않으므로 현재 비활성화되어 있습니다. 하지만 이는 이러한 프로토콜을 QUIC으로 마이그레이션하기 위한 기반을 마련합니다. 다음을 비롯해 기반 기능을 도입하는 여러 PR이 병합되었습니다.
비동기 TPU 연결
v1.17에는 비동기 TPU 클라이언트 연결이 도입되어 연결 캐시 메커니즘이 크게 개선됩니다. 이 업데이트는 기본 연결 풀 크기 4로 백그라운드 연결 설정을 지원해 트랜잭션 지연 시간을 줄이도록 설계되었습니다. 비동기 TPU 클라이언트 연결을 사용하면 동기식 연결에 필요한 대기 시간 없이 트랜잭션을 더 원활하게 처리할 수 있습니다.
간소화된 검증인 시작 및 스냅샷 형식 업데이트
v1.17은 새로운 플래그를 도입하고 지원되는 스냅샷 파일 형식을 업데이트해 검증인 시작 프로세스를 간소화합니다. 그 결과 검증인 시작 시간이 단축됩니다. 다운타임을 줄여 네트워크 복원력을 높인다는 점에서 중요한 변화입니다.
v1.17에는 새로운 –use-snapshot-archives-at-startup 플래그가 도입됩니다. 검증인은 로컬 스냅샷, 디스크에 저장된 로컬 상태 또는 둘 중 최신 항목을 자동으로 선택해 시작 프로세스를 단축할 수 있습니다. 디스크 상태가 더 최신인 경우 스냅샷을 처리할 필요가 없어 재시작 시간이 단축됩니다.
이전에는 Solana가 스냅샷에 다양한 압축 형식을 지원했습니다. 아카이브 형식에는 bz2, gzip, zstd, lz4, tar 및 압축하지 않는 옵션이 있었습니다. 하지만 최신 업데이트에서는 효율성을 최적화하고 지원 복잡성을 줄이기 위해 선택지를 zstd 또는 lz4로 좁혔습니다. 다른 형식은 –snapshot-archive-format 인수에서 더 이상 권장되지 않습니다. 다만 이전 버전과의 호환성을 보장하기 위해 검증인은 이러한 형식의 기존 스냅샷을 계속 읽을 수 있습니다. 이에 따라 solana-validator 및 solana-ledger-tool의 명령줄 인터페이스가 자연스럽게 단순해집니다.
결론
다양한 기능 구현과 최근 네트워크 중단의 신속한 해결을 통해 Solana의 v1.17 업데이트는 크게 도약했습니다. ZK Token Program, Poseidon 시스템 호출, alt_bn128 시스템 호출이 출시되면서 전례 없는 영지식 지원과 기능이 도입됩니다. 검증인과 네트워크 효율성 개선까지 더해져 다음 버전 업데이트를 위한 견고한 기반을 마련합니다. 이번 업데이트는 v1.16보다 규모가 작으며 3개월마다 새 버전을 출시한다는 목표에 부합합니다. 1.18 출시 일정은 여기에서 확인할 수 있습니다.
여기까지 읽어주셔서 감사합니다, 익명의 독자 여러분! 아래에 이메일 주소를 입력해 Solana의 새로운 소식을 빠짐없이 받아보세요. 더 자세히 알아볼 준비가 되셨나요? 지금 Helius 블로그의 최신 글을 살펴보고 Solana 여정을 계속하세요.
추가 자료
Helius 구독하기
최신 Solana 개발 소식을 확인하고 새 게시물 알림을 받아보세요