Solana 새로운 4,096바이트 트랜잭션 제한을 메모리 페이지 하나에 할당했습니다

Solana 9월 9일부터 단일 트랜잭션이 전송할 수 있는 데이터 양을 세 배로 늘릴 예정입니다. GitHub에 게시된 SIMD-0296 제안에 따르면, 이 새로운 4,096바이트 용량은 검증자 하드웨어의 4KiB 메모리 페이지 하나에 저장됩니다.

이제 여러 트랜잭션이 필요한 워크로드가 단 한 번의 원자적 호출로 완료됩니다.

QUIC 프로토콜 덕분에 1,232바이트 용량 제한은 무의미해졌습니다

Solana 원래 제한 사항은 네트워크 관련 주의 사항이었습니다. 네트워크는 1,280바이트의 IPv6 MTU로 작동했습니다.

SIMD-0296의 저자들은 프로토콜 오버헤드를 고려하면 트랜잭션 페이로드에 1,232바이트가 남았다고 설명합니다. 모든 메시지가 단편화 없이 MTU를 통과해야 했기 때문에 이러한 할당량은 타당합니다.

Solana 2022년에 트랜잭션 처리 표준 방식으로 QUIC를 채택했습니다. RFC 9000은 최대 스트림 크기를 설정하지 않으므로 더 큰 페이로드도 네트워크 수준에서 문제없이 전송될 수 있습니다.

1,232바이트라는 제한은 기술적 근거가 전혀 없는 규칙으로 굳어져 버렸다.

두 문서는 안자(Anza) 엔지니어인 제이콥 크리치와 앤드류 피츠제럴드가 작성했습니다. SIMD-0296은 크기 제한을 상향 조정합니다.

SIMD-0385 라는 defi합니다. 이 두 문서는 블록체인 출시 이후 개발자들이 회피해왔던 제약 조건을 해결합니다. 또 다른 문서 는 추가 바이트를 포함하는 v1 메시지 형식을

이 제안은 QUIC에서 허용하는 최대 크기보다 4,096바이트를 선호하여 트랜잭션이 검증자 메모리의 표준 4KiB 페이지 하나에 들어갈 수 있도록 합니다. 따라서 어떤 트랜잭션도 페이지 경계를 넘지 않습니다.

트랜잭션별 메모리 관리 비용은 저렴합니다. 각 트랜잭션은 단일 페이지로 제한됩니다.

크리치와 피츠제럴드는 4,096바이트라는 제한을 도출하기 위해 개발자들이 기존 제한을 우회하기 위해 Jito 번들을 어떻게 사용했는지 분석했습니다

• 제출된 번들의 50%는 2,048바이트 이하였습니다.
• 65%는 6,144바이트 미만이었습니다.
• 100%가 9,216바이트 미만으로 유지되었습니다.

4,096바이트의 상한선은 검증기 하드웨어 페이지 제약 조건 내에서 단일 호출로 이러한 다중 트랜잭션 워크로드의 대부분을 처리할 수 있습니다.

준비되지 않은 RPC 호출 시 Solana 에서 오류 -32015가 발생합니다

추가 용량 덕분에 1,232바이트 제한을 초과하는 워크로드도 처리할 수 있습니다.

토큰 확장 기능의dent전송에 사용되는 것과 같은 영지식 증명은 1,232바이트 제한을 초과하는 페이로드를 생성했습니다.

이 문제를 해결하기 위해 개발자들은 여러 호출을 연결하거나 원자적 암호화 전송을 포기했습니다. 새로운 4,096바이트 제한은 하나의 트랜잭션에 영지식 증명을 수용할 수 있도록 합니다.

BLS 서명 집계 및 대규모 멀티시그 구성 또한 이러한 변경 사항의 혜택을 받습니다. SIMD-0296은 기관 재무 부서와 DAO가 스쿼드를 통해 사용하는 멀티시그 유형인 중첩 멀티시그를 주요 동인 중 하나로 언급합니다.

또한 사전 컴파일 없이 작동하는 윈터니츠 일회용 서명 및 온체인 BLS 체계를 참조합니다.

이 형식은 이전 버전(v0)에서 최대 64개의 계정을 짧은 인덱스로 참조하는 데 사용되었던 주소 조회 테이블을 사용하지 않습니다. 이 테이블은 복잡성만 증가시킬 뿐 이점이 없습니다. 이제 64개의 32바이트 인라인 주소가 사용되며, 이는 2,048바이트만 차지하여 최대 용량 제한보다 훨씬 적습니다.

에서는 모든 거래에 대한 Solana . 데이터 사용량이 많은 애플리케이션은 바이트 예산 문제가 해결되었더라도 여전히 해당 제한에 도달할 수 있습니다. 네트워크 계정 수 제한이 64개로 유지됩니다

Jito 번들을 사용하면 개발자는 최대 5개의 트랜잭션을 일괄 처리하거나 전혀 처리하지 않는 시퀀스로 병합하여 바이트 제한 문제를 해결할 수 있습니다.

트랜잭션 v1은 단일 트랜잭션으로 동일한 원자적 결과를 달성합니다. 이는 기본 레이어에 직접 네이티브 원자성을 제공합니다.

V1은 발신자가 선택적으로 사용할 수 있으므로 기존 및 v0 트랜잭션은 계속 작동합니다. Solana 재단의 마이그레이션 안내에 따르면 이는 블록을 읽는 인프라에 호환성을 깨뜨리는 변경 사항입니다.

데이터 도구와 블록 탐색기가 Solana의 새 버전에 맞게 업데이트되지 않으면 완전히 멈추거나 오류가 발생합니다.

앱이 새 버전 매개변수 없이 v1 트랜잭션이나 블록을 읽으려고 하면 Solana서버는 시스템 오류 코드 -32015와 함께 요청을 거부합니다.

실시간 블록을 지속적으로 스트리밍하는 도구는 새로운 v1 트랜잭션을 만나면 완전히 빈 응답을 받고 거기서 멈추게 됩니다.

거래 데이터를 기록하는 도구인 인덱서는 잘못된 위치를 검색하기 때문에 신규 거래에 대한 우선 수수료가 0으로 표시됩니다.

이전에는 거래 내역 내의 특별 목록에서 이러한 수수료를 확인했습니다. 새 버전에서는 해당 정보가 별도의 요약 상자에 표시됩니다.

Anza는 RPC 제공업체에게 Agave v4.2로 업그레이드할 것을 요구하고 있습니다. Helius는 마이그레이션 작업에 대한 자세한 내용을 담은 체크리스트를 발표했습니다.

트랜잭션 v1은 9월 1일 1025번째 에포크 동안 Solana 테스트넷에서 활성화되었습니다. Anza는 9월 9일을 메인넷 배포일로 공식 발표했습니다.