Sui 테스트넷 Wave 2를 돌아보며, 공식적으로 어떤 주요 정보가 공개되었나요?

작성자：Sui 재단

편집：Babywhale，Foresight News

Sui 테스트넷 Wave 2가 성공적으로 종료되었으며, 이번 테스트는 Sui에서 스테이킹 작업을 수행하는 목표를 달성하는 데 도움을 주었습니다. 네트워크에서의 많은 활동은 우리가 메인넷 출시 여정에서 중요한 단계를 또 한 번 밟았다는 자신감을 주었습니다. Sui를 더 나은 곳으로 만들어 주신 모든 분들께 진심으로 감사드립니다!

우리는 Wave 2에서 많은 것을 배웠으며, 앞으로 Wave 2의 모든 내용을 되돌아보는 세 부분으로 구성된 블로그 시리즈를 발표할 예정입니다. 첫 번째 블로그는 네트워크 측면을 다루고, 이후의 글에서는 토큰 경제학과 Frenemies 게임에 대해 더 깊이 논의할 것입니다.

통계 스냅샷

Wave 2 기간 동안 커뮤니티는 3주, 33개의 epoch 테스트에서 여러 새로운 기록을 공동으로 세웠습니다.

• 7000개 이상의 노드가 41개의 검증기에 연결됨
• 169만 개의 주소
• 3650만 건의 거래(1차 Wave 대비 1.6배 증가)
• 324만 개의 NFT
• 118,614개의 계약이 발행됨(1차 Wave 대비 45배 증가)
• 134만 개의 SUI가 스테이킹됨
• 735만 건의 스테이킹 작업이 처리됨
• 67회의 TPS 피크가 관찰됨
• 1월의 첫 3주와 비교하여 Sui 지갑 DAU는 Wave 2 기간 동안 2.2배 증가하여 17.1만에 도달했으며, Sui 지갑 설치 수는 3배 이상 증가하여 33.3만에 도달함
• Sui 블록 탐색기는 100만 페이지 조회수와 57.1만 독립 방문자를 기록하며 역사적인 신기록을 세움
• Sui Discord 커뮤니티는 60만 명 이상의 회원을 보유하여 세계에서 가장 큰 web3 커뮤니티 중 하나가 됨

특히 Wave 2 기간 동안 100만 건 이상의 거래를 처리한 네 개의 스마트 계약이 있으며, 총 거래량의 40%를 차지합니다:

• Sui의 시스템 객체가 1위를 차지하며, 730만 건 이상의 스테이킹 관련 거래를 처리함.
• Frenemies 게임이 2위로, 단 5일의 게임 시간 동안 350만 건 이상의 거래를 완료함.
• 세 번째로 활발한 스마트 계약은 8192 게임으로, 계약 주소는 0x137aebf47cd16956b68633b6f6f00a992d87d9c6이며, 200만 건 이상의 거래를 처리함.
• 네 번째로 활발한 스마트 계약은 Sui Capys로, 계약 주소는 0x4c10b61966a34d3bb5c8a8f063e6b7445fc41f93이며, 160만 건의 거래를 처리함.

백만 거래를 돌파한 커뮤니티 프로젝트 8192 게임에 특별히 축하를 보냅니다! 또한 Wave 2 데이터 분석을 제공해 준 커뮤니티 프로젝트 Suiscan에도 감사드립니다.

이러한 새로운 기록과 네트워크 활동 수준은 우리가 중요한 소프트웨어 업데이트를 확정하고, 검증자 및 노드 운영자 커뮤니티와 협력하여 운영 능력을 향상시킬 수 있게 해줍니다.

주목할 만한 네트워크 업데이트

Wave 1과 마찬가지로 Wave 2는 Sui 인프라에서 개선이 필요한 부분을 발견하는 것을 목표로 했습니다.

대형 메시지 또는 거래 처리

Wave 2는 스테이킹에 집중했기 때문에 네트워크는 많은 스테이킹 및 언스테이킹 거래를 경험했으며, 이는 대형 네트워크 메시지 및 거래 처리 능력을 향상시키는 데 도움을 주었습니다. 특히, 각 미결 스테이킹 위임 및 언스테이킹 거래는 epoch 변경 기간 동안 이벤트를 생성합니다. 이는 epoch 변경 거래의 거래 크기에 영향을 미치며, 생성된 각 이벤트는 거래 효과의 일부입니다. Wave 2에서는 한 epoch에서 최대 23만 건의 스테이킹 작업이 있었기 때문에 해당 epoch 변경의 거래 효과가 매우 커졌습니다.

이러한 초대형 거래는 많은 문제를 발생시킬 수 있습니다. epoch 변경 거래 효과가 너무 커서 네트워크에서 다운로드할 수 없게 되면 epoch 변경이 실패합니다. 거래 영향이 최대 JSON RPC 응답보다 크면 거래를 검색할 수 없습니다. 이렇게 큰 거래를 로드하려는 모든 애플리케이션(예: 탐색기)은 충돌 위험이 있을 수 있습니다. 이러한 큰 거래는 계산적으로도 너무 비쌀 수 있어 네트워크가 처리할 수 없습니다. Wave 2 기간 동안, 우리 팀은 많은 거래를 처리할 때 네트워크가 정상적으로 작동하도록 하기 위해 몇 가지 긴급 제한을 강화해야 했습니다.

이러한 상황에 대응하기 위해, 우리는 객체(object), 패키지(package) 및 다양한 거래 데이터(입력 매개변수, 거래 효과, 이벤트)에 대한 보호적 크기 제한을 추가하는 작업을 가속화했습니다. 이러한 제한은 메인넷에서 초대형 거래로 인해 저장, 네트워크 및 계산 자원이 압도당하지 않도록 하는 데 도움이 될 것입니다.

거래의 유형 매개변수 입력을 보다 견고하게 처리

2월 1일, 우리는 Move 모듈을 유형 매개변수의 거래 입력으로 지정할 경우 거래 처리 논리가 Move 모듈의 의존성을 올바르게 검증하지 못하는 오류를 발견했습니다(즉, 해당 유형이 속한 모듈이 게시되었는지 여부). Move 패키지 게시가 비잔틴 일관성 브로드캐스트의 빠른 경로를 통해 이루어지기 때문에 일부 검증자는 다른 검증자보다 먼저 게시된 Move 모듈을 알 수 있으며, 이 모듈을 유형 매개변수에서 사용하는 거래의 유효성에 동의하지 않을 수 있습니다. 이러한 거래 하나가 시스템이 다음 체크포인트를 형성하는 것을 방해하여 많은 전체 노드가 중단되고 검증자가 네트워크를 분기하게 만들었습니다. 이는 2월 1일 새벽 Wave 2 중단의 주요 원인이었습니다.

유형 매개변수에 입력된 모듈이 무효한 제출 거래가 존재하는 상황에서 테스트넷을 운영하기 위해, 우리 팀은 몇 가지 긴급 수정을 수행했습니다:

• 항상 유형 매개변수의 모듈이 게시되었는지 확인합니다;
• 제출된 무효 거래가 실패로 실행을 완료하도록 허용합니다;
• 게시되지 않은 유형 매개변수를 가진 추가 거래의 제출을 방지합니다.

그 후 우리는 두 번째 오류를 발견했습니다. 거래 입력 검사 논리가 Move 모듈이 아닌 계약을 유형 매개변수에 삽입하는 것을 거부하지 않았습니다. 유형 매개변수는 반드시 Move 모듈이어야 하므로 거래는 결코 완료되지 않으며 다음 체크포인트를 형성할 수 없습니다. 마찬가지로, 우리 팀은 문제가 있는 거래가 실행 오류로 인해 실패하도록 강제하는 긴급 수정을 추가해야 했습니다.

우리는 Sui의 코드베이스에 이 두 오류의 수정 사항을 추가했습니다: 입력 객체 생성 수정 #7940.

Narwhal 합의 메커니즘 지연 개선

Wave 1과 마찬가지로 테스트넷 Wave 2는 41개의 분산 검증자를 가진 Narwhal 합의를 추가로 테스트할 수 있는 귀중한 기회를 제공했습니다. Wave 2 기간 동안, 우리는 이 기회를 활용하여 몇 가지 합의 지연 감소 최적화를 수행했습니다(두 검증자에 대한 병렬 합의 제출、병렬 인증서 검증、minheaderdelay 매개변수、1초의 minheaderdelay）。우리는 성능을 지속적으로 반복하고 있으며 곧 더 많은 최적화 계획을 출시할 것입니다.

주목할 만한 개발자 경험 교훈

네트워크의 안정성을 보장하는 것이 최우선 과제이지만, 우리의 장기 목표는 Sui를 최고의 스마트 계약 개발자 플랫폼으로 만드는 것입니다. 개발자는 Sui를 기반으로 Web3.x에서 최고의 경험을 창출할 수 있습니다. 이를 위해 우리는 Wave 2 기간 동안 개발자와 사용자 간의 마찰 지점에 주목했습니다.

토큰 관리

Wave 2 기간 동안 몇 가지 요인으로 인해 사용자가 토큰 관리 문제를 겪을 가능성이 있었습니다. 이러한 문제는 일반적으로 가스 요금 부족 오류로 나타나거나 사용자가 거래를 수행하기에 충분한 SUI 잔액을 보유하고 있는 것처럼 보일 때 회색의 스테이킹 버튼이 나타나는 형태로 나타났습니다.

Foresight News가 네트워크에서 활발하게 진행되면서 가스 가격이 변동할 수 있으며, 각 epoch 간에 정상보다 더 큰 증가가 발생했습니다. 높은 가스 가격의 변동은 사용자가 보유한 단일 토큰의 가치가 가스 요금을 지불하기에 충분하지 않을 수 있습니다. 둘째, 초기 참조 가스 가격 설정이 Devnet보다 더 높아 사용자가 여러 종류의 토큰을 보유할 가능성이 줄어들고, 자주 토큰을 소진하게 됩니다. 마지막으로, 스테이킹 작업은 본질적으로 사용자가 기존 SUI 잔액을 하나 이상의 검증자에게 위임하는 것을 포함합니다. 그러나 사용자가 보유한 SUI의 배치가 항상 그들이 예상한 스테이킹 작업과 일치하지 않을 수 있습니다.

우리는 Wave 2 기간 동안 이러한 상황을 완화하기 위해 몇 가지 변경을 수행했습니다:

• 높은 참조 가스 가격 기간 동안 기본 faucet 수를 늘렸습니다;
• 우리는 해결했습니다 Sui 클라이언트가 gas_budget보다 큰 가스 객체를 선택하는 SDK 버그;
• Sui 지갑 스테이킹에 기본 토큰 관리를 추가했습니다. 여기서 각 스테이킹 작업에 대해 우리는 paySui 거래를 사용하여 스테이킹과 가스 지불을 위한 모듈을 각각 구축했습니다.
• 우리는 곧 프로그래머블 거래를 지원할 계획이며, 이는 애플리케이션의 토큰 관리를 간소화할 것입니다.

이번 테스트의 다른 수확

각 테스트넷 Wave는 긴장과 흥분의 조합입니다. 우리는 Sui 커뮤니티의 모든 사람과 협력하여 네트워크의 스테이킹 능력을 극한으로 끌어올리려 했으며, 이러한 정신으로 Wave 2 기간 동안 Sui를 성공적으로 강화했습니다.

우리는 커뮤니티의 적극적인 참여에 깊이 감사드리며, 이는 높은 부하를 생성하고 문제를 발견하는 데 도움이 되었습니다. 우리의 다음 이정표는 개발자 커뮤니티를 위해 영구적인 테스트넷을 시작하는 것이며, 이는 더 이상 임시적이지 않을 것이며, 우리는 그때 더 많은 협력을 기대합니다.