Solana v1.18 업데이트의 모든 것

소개

Solana 1.18 업데이트가 압도적 다수의 채택을 달성한 것은 중요한 이정표입니다. 네트워크의 성능, 안정성, 효율성을 높이기 위한 다양한 개선 사항과 새로운 기능이 도입됩니다. 가장 주목할 만한 변화 중 하나는 중앙 스케줄러의 도입입니다. 이 새로운 스케줄러는 트랜잭션 처리를 간소화하고 우선순위를 더 정확하고 효율적으로 계산하는 것을 목표로 합니다. 런타임 환경과 프로그램 배포에 적용된 여러 개선 사항도 네트워크 부하가 가장 높은 시기에도 더 안정적인 성능을 제공합니다.

이 글에서는 1.18 릴리스에 포함된 업데이트와 개선 사항을 살펴봅니다. 이러한 변경의 배경과 새로운 기능의 세부 사항, 그리고 네트워크 개선에 미칠 것으로 예상되는 영향을 알아봅니다. 검증인 운영자, 개발자, 일반 Solana 사용자 모두 이 종합적인 1.18 업데이트 개요를 통해 새로운 개선 사항을 이해하고 활용하는 데 필요한 정보를 얻을 수 있습니다.

먼저 이러한 변화를 주도하는 신생 개발사 Anza와 Solana의 지속적인 개발에서 Anza가 맡은 역할을 살펴보겠습니다.

Anza란?

Anza는 Solana Labs의 전직 임원과 핵심 엔지니어들이 설립한 신생 소프트웨어 개발사입니다. Anza의 출범은 Solana 생태계의 안정성, 탈중앙화, 네트워크 역량을 강화하기 위한 전략적 행보입니다. Anza는 핵심 인프라를 개발하고 주요 프로토콜에 기여하며 새로운 도구의 혁신을 촉진함으로써 Solana 생태계를 발전시키기 위해 설립되었습니다.

창립 팀에는 Jeff Washington, Stephen Akridge, Jed Halfon, Amber Christiansen, Pankaj Garg, Jon Cinque와 Solana Labs의 여러 핵심 엔지니어가 포함됩니다.

Anza는 Solana Labs 검증인 클라이언트의 포크인 Agave를 만들어 Solana 검증인 클라이언트를 개발하고 개선하는 데 집중합니다. Anza의 목표는 자체 검증인 클라이언트 개발에 그치지 않고 생태계 전반을 개선하는 데까지 확장됩니다. 여기에는 Token Extensions와 맞춤형 Rust / Clang 툴체인 개발이 포함됩니다. Anza는 협업 중심의 개방적인 개발 방식을 통해 Solana 생태계의 발전과 개선을 가속하는 데 전념합니다.

Agave란?

앞에서 간단히 언급했듯이 Agave는 Anza가 주도하는 Solana Labs 검증인 클라이언트의 포크입니다. 여기서 “포크”란 Anza 개발 팀이 Solana Labs 저장소의 기존 코드를 가져와 원래 코드베이스와 별개인 새로운 개발 경로를 시작했다는 뜻입니다. 이를 통해 Anza는 Solana Labs 클라이언트에 자체 개선 사항과 기능, 최적화를 구현할 수 있습니다.

마이그레이션 과정

클라이언트를 Anza의 GitHub 조직으로 이전하는 작업은 3월 1일에 시작되었습니다. 초기에는 커뮤니티가 적응할 시간을 확보할 수 있도록 Agave가 Solana Labs 저장소를 미러링합니다. 이 기간에 Anza는 풀 리퀘스트(PR)를 종료하고 관련 이슈를 Agave 저장소로 이전합니다. Agave와 Solana Labs 클라이언트 버전 1.17 및 1.18은 기능 면에서 동일합니다. Anza는 올여름 Agave v2.0을 출시할 계획입니다. 이 과정에서 Solana Labs 클라이언트를 보관 처리하고 네트워크 전체가 새로운 Agave 클라이언트로 마이그레이션하도록 권장할 예정입니다.

Solana Labs에서 Agave로의 마이그레이션 과정은 GitHub에서 공개적으로 추적됩니다.

Agave 런타임

Agave 런타임은 Solana Virtual Machine (SVM)의 기본 아키텍처를 계승하며, Sealevel 런타임이 정의하는 핵심 기능을 실행하는 기반입니다. 

Solana 프로토콜은 런타임을 트랜잭션을 처리하고 계정 데이터베이스의 상태를 업데이트하는 핵심 구성 요소로 규정합니다. Agave와 Firedancer 클라이언트는 이 사양을 채택하고 더욱 개선했습니다. SVM의 핵심은 모든 Solana 프로그램을 실행하고 계정 상태를 병렬로 변경하는 역량입니다.

뱅크 개념은 트랜잭션 처리와 1.18의 변경 사항을 이해하는 데 중요합니다. 뱅크는 로직의 일부이자 특정 시점의 원장 상태를 나타내는 표현입니다. 계정 데이터베이스를 관리하고, 클라이언트 계정 추적과 프로그램 실행을 감독하며, Solana 원장의 무결성과 진행 상태를 유지하는 정교한 컨트롤러 역할을 합니다. 뱅크는 특정 블록에 포함된 트랜잭션의 결과 상태를 캡슐화하며 해당 시점 원장의 스냅샷 역할을 합니다.

각 뱅크에는 트랜잭션 실행에 필요한 캐시와 참조가 있으며, 이전 스냅샷이나 제네시스 블록에서 초기화할 수 있습니다. 검증인이 트랜잭션을 처리하는 Banking Stage에서는 뱅크를 사용해 블록을 구성한 후 무결성을 검증합니다. 이 수명 주기에는 계정 로드, 트랜잭션 처리, 상태 확정을 위한 뱅크 동결, 최종적인 루트 지정이 포함되며 이를 통해 영속성이 보장됩니다.

개괄적으로 Agave 런타임의 트랜잭션 처리 엔진은 프로그램을 로드하고 컴파일하며 실행합니다. Just-In-Time (JIT) 컴파일을 사용하고 컴파일된 프로그램을 캐시하여 실행 효율성을 최적화하며 불필요한 재컴파일을 줄입니다. 프로그램은 배포 전에 eBPF 형식으로 컴파일됩니다. 이후 런타임은 rBPF 툴킷을 사용해 eBPF 가상 머신을 생성합니다. 이 가상 머신은 eBPF를 x86_64 머신 코드 명령어로 JIT 컴파일하여 가용 하드웨어를 최대한 활용합니다. 이를 통해 프로그램을 효율적으로 실행합니다.

1.18 업데이트에는 Agave 런타임이 제공하는 운영 효율성과 밀접하게 연결된 중앙 트랜잭션 스케줄러가 도입됩니다. 1.18 업데이트는 뱅크를 통한 트랜잭션 컴파일, 실행, 관리 방식을 개선해 스케줄링 프로세스를 더 간결하고 효율적으로 만듭니다. 이에 따라 트랜잭션 처리 시간이 단축되고 처리량이 향상됩니다. 새로운 Agave 런타임과 클라이언트는 이러한 개선의 토대입니다. 따라서 새로운 스케줄러의 세부 사항을 살펴보기 전에 전반적인 내용을 이해하는 것이 중요합니다. 

Agave 런타임을 더 자세히 알아보려면 Joe Caulfield의 관련 글을 읽어보세요. 상당히 상세한 설명과 유용한 코드 예시를 제공합니다.

더 효율적인 트랜잭션 스케줄러

현재 구현 방식

트랜잭션 처리 파이프라인에서 트랜잭션 패킷은 먼저 패킷 인그레스를 통해 시스템에 진입합니다. 이후 패킷은 SigVerify 단계에서 서명 검증을 거칩니다. 이 단계에서는 각 트랜잭션이 유효하며 발신자의 승인을 받았는지 확인합니다.

서명 검증이 끝나면 트랜잭션은 Banking Stage로 전송됩니다. Banking Stage에는 6개의 스레드가 있습니다. 2개는 Transaction Processing Unit (TPU) 또는 Gossip에서 받은 투표 트랜잭션을 처리하고, 4개는 비투표 트랜잭션을 처리합니다. 각 스레드는 서로 독립적이며 공유 채널에서 패킷을 받습니다. 즉, SigVerify가 패킷을 배치 단위로 전송하면 각 스레드가 공유 채널에서 트랜잭션을 가져와 로컬 버퍼에 저장합니다. 

로컬 버퍼는 트랜잭션을 받아 우선순위를 결정한 뒤 그에 따라 정렬합니다. 이 큐는 동적으로 작동하며 트랜잭션 상태와 네트워크 수요의 실시간 변화를 반영하도록 계속 업데이트됩니다. 트랜잭션이 큐에 추가될 때마다 순서를 다시 평가하여 우선순위가 가장 높은 트랜잭션부터 처리할 수 있도록 준비합니다.

이 과정은 계속 진행되며 트랜잭션 패킷의 처리 방식은 검증인이 리더 스케줄에서 어느 위치에 있는지에 따라 달라집니다. 검증인이 가까운 시일 내에 리더가 될 예정이 아니라면 패킷을 다음 리더에게 전달한 뒤 폐기합니다. 예정된 리더 슬롯이 가까워지면(약 20슬롯 전) 패킷을 계속 전달하되 더 이상 폐기하지 않습니다. 다른 리더가 처리하지 않을 경우 이 패킷을 자신의 블록 중 하나에 포함할 수 있도록 하기 위함입니다. 검증인이 리더가 되기 2슬롯 전부터는 패킷을 보관하기 시작합니다. 패킷을 수신한 뒤 아무 작업도 하지 않고 대기하며 리더가 되었을 때 처리합니다.

블록 생성 중 각 스레드는 로컬 큐에서 상위 128개 트랜잭션을 가져와 잠금 획득을 시도한 다음 트랜잭션을 검사, 로드, 실행, 기록, 커밋합니다. 잠금 획득에 실패하면 해당 트랜잭션은 나중에 다시 시도됩니다. 각 단계를 자세히 살펴보겠습니다.

• 잠금: 스레드가 어떤 트랜잭션의 잠금을 획득할 수 있는지 확인합니다. 각 트랜잭션은 일정 수의 계정을 읽고 쓰므로 검증인은 충돌이 없는지 확인해야 합니다
• 검사: 트랜잭션이 너무 오래되었거나 이미 처리되었는지 확인합니다. 뱅크에는 최근 150~300슬롯의 트랜잭션을 추적하는 상태 캐시가 있습니다
• 로드: 특정 트랜잭션 실행에 필요한 계정을 로드합니다. 수수료 지불자가 실제로 수수료를 낼 수 있는지, 호출된 프로그램이 유효한지도 확인합니다. 기본적으로 계정을 로드하고 초기 설정을 수행하는 단계입니다
• 실행: 각 트랜잭션을 실행합니다
• 기록: 실행된 트랜잭션의 결과를 Proof of History Service로 보내 해싱합니다. 이 단계에서 트랜잭션 서명이 전송됩니다
• 커밋: 기록 단계가 성공하면 트랜잭션이 커밋됩니다. 또한 변경 사항을 계정 시스템에 다시 반영하므로 현재 슬롯이나 이후 슬롯의 향후 트랜잭션에서 각 계정의 업데이트된 상태를 확인할 수 있습니다‍
• 잠금 해제: 첫 단계에서 각 계정에 설정한 잠금을 해제합니다

Banking Stage는 다중 반복자 방식을 사용해 트랜잭션 배치를 만듭니다. 다중 반복자는 여러 시퀀스로 데이터 세트를 동시에 순회할 수 있는 프로그래밍 패턴입니다. 여러 독자가 한 권의 책을 서로 다른 장에서 읽기 시작하되, 내용 이해가 서로에게 영향을 줄 수 있는 경우 같은 페이지를 동시에 읽지 않도록 조율하는 모습을 떠올리면 됩니다. Banking Stage에서 이 “독자”는 반복자이며 “책”은 처리를 기다리는 트랜잭션 모음입니다. 다중 반복자의 목표는 트랜잭션을 효율적으로 선별해 잠금 충돌 없이 처리할 수 있는 배치로 그룹화하는 것입니다.

처음에는 우선순위에 따라 트랜잭션을 벡터로 직렬화합니다. 이를 통해 다중 반복자가 트랜잭션을 충돌 없는 배치로 분할할 수 있는 구조화된 시퀀스를 얻습니다. 다중 반복자는 직렬화된 벡터의 시작점에서 출발해 트랜잭션이 서로 충돌하지 않는 지점에 반복자를 배치합니다. 이 방식으로 읽기-쓰기 또는 쓰기-쓰기 충돌이 없는 128개 트랜잭션의 배치를 만듭니다. 트랜잭션이 현재 구성 중인 배치와 충돌하면 건너뛰고 표시하지 않습니다. 따라서 충돌이 사라진 후속 배치에 포함될 수 있습니다. 이 반복 과정은 트랜잭션 처리가 계속되는 동안 동적으로 조정됩니다. 

배치 구성이 완료되면 트랜잭션을 실행합니다. 성공할 경우 Proof of History Service에 기록하고 네트워크에 브로드캐스트합니다.

현재 구현 방식의 문제점

현재 구현에는 성능에 악영향을 줄 수 있는 여러 영역이 있습니다. 이로 인해 트랜잭션 처리에 병목 현상이 발생하고 우선순위 지정이 일관되지 않을 수 있습니다. 이러한 문제는 주로 Banking Stage의 아키텍처와 시스템 내부의 트랜잭션 처리 방식에서 비롯됩니다.

근본적인 문제는 비투표 트랜잭션을 처리하는 4개의 독립적인 스레드가 각 스레드 안에서 서로 다른 트랜잭션 우선순위 관점을 가진다는 것입니다. 이 차이로 인해 트랜잭션 순서에 지터나 불일치가 발생할 수 있습니다. 우선순위가 높은 모든 트랜잭션이 충돌하면 이러한 불일치가 더욱 두드러집니다. 각 스레드는 기본적으로 SigVerify의 공유 채널에서 패킷을 무작위로 가져오므로 전체 트랜잭션 중 임의의 세트를 보유하게 됩니다. 인기 NFT 민팅과 같이 경쟁이 치열한 이벤트에서는 우선순위가 높은 여러 트랜잭션이 복수의 Banking Stage 스레드에 분산될 가능성이 큽니다. 이는 스레드 간 잠금 충돌을 일으킬 수 있어 문제가 됩니다. 서로 다른 우선순위 세트를 처리하는 스레드들이 우선순위가 높은 트랜잭션을 먼저 처리하려고 경쟁하면서 잠금 획득 실패로 처리 시간이 낭비될 수 있습니다.

Banking Stage를 각 스레드가 현악기, 금관악기, 목관악기, 타악기처럼 서로 다른 파트를 맡는 오케스트라라고 생각해 보세요. 이상적으로는 지휘자가 각 파트를 조율하여 조화로운 연주를 이끌어야 합니다. 하지만 현재 시스템은 지휘자 없이 복잡한 곡을 연주하는 오케스트라와 비슷합니다. 각 파트가 제각기 연주하며 계속 충돌합니다. 우선순위가 높은 트랜잭션은 모든 파트가 동시에 연주하려는 독주 부분과 같아 혼란을 일으킵니다. 오케스트라를 이끄는 지휘자처럼 Solana의 트랜잭션 처리를 효율적이고 조화롭게 만들 중앙화된 “지휘자”가 필요합니다.

새로운 트랜잭션 스케줄러

1.18 업데이트에는 중앙 스케줄링 스레드가 도입됩니다. 각자 트랜잭션의 우선순위를 지정하고 처리하던 4개의 독립적인 뱅킹 스레드 모델을 대체합니다. 새로운 구조에서는 중앙 스케줄러만 SigVerify 단계에서 트랜잭션을 받습니다. 중앙 스케줄러는 우선순위 큐를 만들고 종속성 그래프를 활용해 트랜잭션 우선순위 지정과 처리를 관리합니다.

이 종속성 그래프를 prio-graph라고 합니다. 새로운 트랜잭션이 추가될 때 지연 평가되는 방향성 비순환 그래프입니다. 트랜잭션은 실행 체인을 구성하도록 그래프에 삽입된 뒤 시간 우선순위 순으로 추출됩니다. 충돌하는 트랜잭션은 먼저 삽입된 트랜잭션이 항상 더 높은 우선순위를 갖습니다. 위 예시에는 A부터 H까지의 트랜잭션이 있습니다. 트랜잭션 A와 E는 각 체인에서 우선순위가 가장 높으며 서로 충돌하지 않습니다. 스케줄러는 왼쪽에서 오른쪽으로 이동하며 트랜잭션을 배치 단위로 처리합니다.

첫 번째 배치에서 트랜잭션 A와 E를 처리하고, 이어서 B와 F, 그다음 C, D, G를 처리하며 마지막 배치에서 H를 처리합니다. 그래프 상단, 즉 가장 왼쪽에 우선순위가 가장 높은 트랜잭션이 있습니다. 스케줄러는 트랜잭션을 내림차순으로 검토하며 충돌을 식별합니다. 트랜잭션이 더 높은 우선순위의 트랜잭션과 충돌하면 이 종속성을 나타내는 에지가 그래프에 생성됩니다. 예를 들어 C와 D는 B와 충돌합니다.

새로운 스케줄러 모델은 다중 반복자 방식에 내재된 몇 가지 핵심 문제를 해결합니다.

• 일관된 우선순위 처리: 새로운 시스템은 트랜잭션 수신과 스케줄링을 중앙화해 모든 트랜잭션이 일관된 우선순위에 따라 처리되도록 합니다. 여러 스레드가 트랜잭션 우선순위를 서로 다르게 판단해 발생하던 지터를 제거합니다
• 처리 지연 감소: prio-graph는 실행을 위해 준비된 배치가 잠금 충돌 없이 성공할 가능성을 크게 높여 처리 시간과 잠금 경합으로 인한 지연을 줄입니다. 여기서 “성공할 가능성을 크게 높인다”는 표현에 유의하세요. prio-graph가 잠금 획득에 실패할 수 없는 배치를 만든다는 의미는 아닙니다. 투표 스레드와 충돌할 수 있지만 이는 매우 드문 예외 사례입니다
• 확장성과 유연성: 새로운 스케줄러 설계에서는 잠금 충돌 증가를 우려하지 않고 스레드 수를 늘릴 수 있습니다. 잠금을 중앙에서 파악하고 작업자 간 트랜잭션 분배를 더 체계적으로 제어하기 때문입니다 

1.18의 중앙 스케줄러 도입으로 트랜잭션 처리가 크게 개선되고 기존 시스템의 복잡성과 오버헤드가 줄어들 것으로 예상됩니다. 트랜잭션 처리 시간은 단축되고 처리량은 증가하며 네트워크는 더 안정적으로 운영될 가능성이 큽니다. 1.18 출시가 지연되는 동안 스케줄러는 처음보다 더 개선되었습니다. 예를 들어 효율성을 높이기 위해 트랜잭션의 사전 컴파일 검증을 작업자 스레드로 옮겼습니다. 또한 CU 한도가 더 합리적으로 조정되어 기존 스케줄러보다 추정치와 실제 사용량의 비율이 훨씬 낮아졌습니다. 이제 새로운 스케줄러는 CU를 사용해 예약된 작업 큐를 제한할 수 있으므로 계정 충돌로 과도한 작업이 큐에 쌓이는 것을 방지합니다.

중앙 스케줄러는 기본적으로 활성화되지 않으며 검증인을 시작할 때 새로운 --block-production-method central-scheduler 플래그를 사용해 활성화해야 합니다. 현재는 선택 사항이지만 향후 릴리스에서는 기본 스케줄러가 됩니다. 기존 스케줄러는 --block-production-method thread-local-multi-iterator 플래그로 활성화할 수 있습니다. 현재 기본적으로 활성화되어 있지만 향후 릴리스에서는 사용하지 마세요. 중앙 스케줄러가 훨씬 효율적이며 기존 스케줄러의 문제를 해결합니다.

더 효과적인 우선순위 계산 

1.18은 트랜잭션 우선순위를 결정하는 방식도 개선해 리소스 사용과 비용 회수 측면에서 더 공정하고 효율적인 프로세스를 제공합니다. 이전에는 트랜잭션 우선순위가 주로 컴퓨팅 예산 우선순위에 따라 결정되어 컴퓨팅 유닛 가격이 최적화되지 않는 경우가 있었습니다. 우선순위 지정 시 징수되는 기본 수수료가 충분히 고려되지 않았기 때문입니다. 이로 인해 리소스 가격이 지나치게 낮게 책정되어 네트워크 운영 효율성에 영향을 줄 수 있었습니다.

새로운 방식은 우선순위 = 수수료 / (비용 + 1) 공식을 사용해 트랜잭션 수수료와 관련 비용을 고려하도록 트랜잭션 우선순위 계산을 조정합니다. 여기서 수수료는 특정 트랜잭션과 관련된 트랜잭션 수수료를 의미하고, 비용은 Solana 비용 모델에 따라 결정되는 컴퓨팅 및 리소스 소비량을 의미합니다. 분모에 “1”을 더하는 것은 0으로 나누는 일을 방지하기 위한 안전장치입니다. 

공식을 더 세분화해 수수료와 비용을 구체적으로 나타낼 수 있습니다.

이제 트랜잭션 비용은 관련된 모든 컴퓨팅 및 운영 비용을 고려해 종합적으로 계산됩니다. 따라서 우선순위 계산에 트랜잭션의 실제 리소스 소비량이 반영됩니다. 개발자와 사용자가 더 적은 컴퓨팅 유닛을 요청하면 더 높은 우선순위를 받게 됩니다. 또한 우선순위 수수료가 없는 단순 전송도 큐에서 일정한 우선순위를 갖습니다.

개선된 프로그램 배포

1.18은 배포 안정성과 실행 효율성 측면에서도 프로그램 배포를 크게 개선합니다. 

새 업데이트는 에포크의 마지막 슬롯에 배포된 프로그램이 다음 에포크에 예정된 런타임 환경 변경 사항을 올바르게 적용하지 못하던 문제를 해결합니다. 이전에는 이 전환 기간에 배포된 프로그램이 잘못된 이전 런타임 환경을 사용했습니다. 1.18에서는 에포크 마지막에 배포되는 모든 프로그램의 런타임 환경이 다음 에포크의 환경과 일치하도록 배포 프로세스를 조정합니다.

1.18은 CLI 프로그램 배포 명령에 --with-compute-unit-price 플래그를 추가하여 배포 트랜잭션에 컴퓨팅 유닛 가격이나 한도를 설정할 수 없던 문제도 해결합니다. 이 플래그는 solana program deploy 및 solana program write-buffer 명령과 함께 사용할 수 있습니다. 각 배포 트랜잭션 유형을 시뮬레이션하고 소비된 컴퓨팅 유닛 수를 기준으로 컴퓨팅 유닛 한도를 설정합니다.  

또 다른 중요한 개선 사항은 대규모 프로그램 배포에서 블록해시를 처리하는 방식입니다. 1.18 이전에는 sign_all_messages_and_send와 함께 전송된 트랜잭션이 100 TPS로 제한되었습니다. 대규모 프로그램의 배포 트랜잭션 수는 수천 개에 달할 수 있습니다. 이 중 다수가 한 번에 10초 넘게 지연되면서 만료된 블록해시를 사용할 위험이 있었습니다. 1.18에서는 제한 지연이 끝날 때까지 최근 블록해시를 사용한 배포 트랜잭션 서명을 미룹니다. 이제 블록해시는 5초마다 갱신되므로 트랜잭션이 500개를 넘는 배포에서 더 최근 블록해시를 사용할 수 있습니다.

또한 1.18은 네트워크의 프로그램 배포 처리와 트랜잭션 검증 방식을 개선합니다. 이전에는 계정 상태 식별 오류로 일부 프로그램이 FailedVerification으로 잘못 표시되었습니다. 실제로 어떤 검사에도 실패하지 않은 프로그램에 잘못된 레이블이 지정될 수 있었습니다. 이제 활성 상태가 아니어야 하는 프로그램은 Closed로 올바르게 식별됩니다. 이 변경으로 문제가 있는 프로그램만 재검사 대상으로 지정되어 불필요한 재검증을 방지할 수 있습니다.

프로그램 상태 업데이트 과정도 개선되었습니다. 이제 프로그램은 배포된 슬롯 안에서 Closed 상태에서 활성 상태로 전환될 수 있습니다. 이에 따라 프로그램이 더 빠르고 안정적으로 작동하기 시작합니다. 수요가 많은 시기에 특히 중요합니다. 다만 이 개선 사항에도 1슬롯의 배포 취소/재배포/배포 쿨다운과 1슬롯의 가시성 지연이 적용됩니다. 따라서 이러한 조정은 네트워크 부하를 더 효과적으로 관리하고 특정 유형의 혼잡을 방지하지만 dApp 개발자의 워크플로를 크게 바꾸지는 않습니다.

“혼잡 패치” — 혼잡을 더 효과적으로 처리하기

“혼잡 패치”로 불린 Testnet 버전 1.18.11은 최근 Solana의 혼잡을 해결하기 위한 변경 사항을 제안했습니다. 이 릴리스는 1.18에만 적용되는 것이 아니며 1.17.31에도 백포트되었습니다. 그럼에도 반드시 살펴봐야 할 중요한 내용입니다.

가장 큰 변화는 QUIC이 Stake-Weighted Quality of Service (SWQoS)에서 스테이킹 규모가 매우 작은 피어를 스테이킹하지 않은 피어로 취급한다는 점입니다. 스테이킹 규모가 매우 작은 노드가 시스템을 악용해 불균형하게 많은 대역폭을 확보할 수 있는 문제를 해결하기 위한 변경입니다. 또한 기존 지표로는 스테이킹된 노드와 스테이킹되지 않은 노드에서 전송되거나 제한된 패킷의 비율을 파악할 수 없었습니다. 따라서 가시성을 높이기 위해 이러한 지표가 추가되었습니다. 스트림은 패킷 크기이므로 그 수가 적을 것으로 예상할 수 있습니다. 이에 따라 패킷당 한 번의 할당을 줄이기 위해 vec 인스턴스를 smallvec으로 교체하여 패킷 청크 처리 방식도 최적화했습니다. 

이전에는 Banking Stage에서 모든 패킷을 다음 노드로 전달했습니다. 하지만 1.18에서는 스테이킹된 노드의 패킷만 전달하도록 변경됩니다. 따라서 앞으로 스테이킹된 연결은 우선순위 계산과 트랜잭션 전달에서 더 큰 비중을 차지하며 그 어느 때보다 중요해집니다.

개선된 문서

1.18 업데이트는 전 세계 사용자의 접근성을 높이기 위해 공식 Solana 문서의 번역 지원도 크게 개선합니다. 업데이트에는 언어 간 문서 동기화를 간소화하는 Crowdin CLI 및 구성 업그레이드와 Docusaurus를 통한 로컬 테스트를 개선하는 새로운 serve 명령 도입이 포함됩니다. 또한 번역된 빌드에서 상대 경로 문제가 발생하지 않도록 PDF 파일을 GitHub blob에 직접 연결하여 정적 콘텐츠 처리 방식도 개선합니다.

개발자가 번역에 기여하는 과정도 필요한 환경 변수와 일반적인 빌드 오류 같은 흔한 문제의 처리 방법을 설명하는 업데이트된 README를 통해 더 명확해졌습니다. 지속적 통합 흐름도 개선되어 이제 안정 채널 빌드에만 번역이 포함됩니다. 이를 통해 검증된 안정적인 문서만 최종 사용자에게 제공됩니다. 이러한 변경은 기여 과정을 간소화하고 공식 문서의 품질을 높이며 모든 사용자가 신뢰할 수 있고 정확한 정보에 접근하도록 하는 것을 목표로 합니다.

결론

Anza가 주도한 1.18 업데이트는 트랜잭션 처리, 우선순위 계산, 프로그램 배포, 공식 문서, 전반적인 네트워크 성능을 크게 개선합니다. 중앙 스케줄러 도입과 최근 혼잡 문제를 해결하기 위한 여러 수정 사항을 통해 Solana는 최대 부하를 더 효과적으로 처리하고 효율적이고 안정적인 네트워크 운영을 보장할 수 있게 되었습니다. Solana는 확장 가능한 블록체인을 구현할 가장 유력한 후보이며, 이번 업데이트는 그 잠재력을 다시 한번 입증합니다.

여기까지 읽어주셔서 감사합니다, 익명의 독자님! 아래에 이메일 주소를 입력하고 Solana의 새로운 소식을 빠짐없이 받아보세요. 더 깊이 알아볼 준비가 되셨나요? 지금 Helius 블로그의 최신 글을 살펴보고 Solana 여정을 이어가세요.

추가 자료

• Agave 클라이언트
• Agave 전환 일정
• Anza
• Prio-graph Crate
• Solana Banking Stage와 스케줄러
• 집중 조명: Solana 스케줄러