Sui testnet Wave 2에 대한 유용한 네트워크 업데이트는 무엇입니까?

Foresight News

特邀专栏作者

2023-02-28 09:45

이 기사는 약 2472자로, 전체를 읽는 데 약 4분이 소요됩니다

테스트 네트워크 Wave 2의 다중 데이터 성능은 Wave 1을 훨씬 능가하며 대규모 트랜잭션, 유형 매개 변수 입력 및 합의 지연에서 개선되었습니다.

AI 요약

펼치기

테스트 네트워크 Wave 2의 다중 데이터 성능은 Wave 1을 훨씬 능가하며 대규모 트랜잭션, 유형 매개 변수 입력 및 합의 지연에서 개선되었습니다.

편집 원본: Babywhale, Foresight News

Sui 테스트넷 Wave 2가 성공적으로 종료되었으며, 이 테스트는 Sui에 스테이킹하려는 우리의 목표를 달성하는 데 도움이 되었습니다. 네트워크에서의 활동량은 우리가 메인넷 출시를 향한 여정에서 또 다른 중요한 단계를 밟았다는 확신을 갖게 했습니다. 더 나은 Sui를 만들기 위해 참여하고 도움을 주신 모든 분들께 큰 감사를 드립니다!

우리는 Wave 2에서 많은 것을 배웠으며 앞으로 Wave 2의 모든 내용을 검토하는 3부작 블로그 시리즈를 게시할 예정입니다. 첫 번째 블로그는 네트워킹 측면을 다루며, 다음 기사에서는 토큰 경제학과 Frenemies 게임에 대해 더 깊이 논의할 것입니다.

통계 스냅샷

웨이브 2 동안 커뮤니티는 3주 동안 33번의 테스트 기간 동안 여러 개의 새로운 기록을 공동으로 세웠습니다.

41개의 유효성 검사기에 연결된 7000개 이상의 노드
169만 개의 주소
3,650만 건의 거래(1차 대비 1.6배 증가)
324만 NFT
118,614 계약 발행(1차 대비 45배 증가)
134만 SUI 서약
735만 건의 스테이킹 작업 처리
67 TPS 스파이크 관찰됨
Sui Wallet DAU는 Wave 2 기간 동안 2.2배 증가한 171,000개였으며 Sui Wallet 설치는 1월 첫 3주에 비해 3배 이상 증가한 333,000개였습니다.
Sui 블록 탐색기는 100만 페이지 뷰와 571k 고유 방문자로 사상 최고 기록을 세웠습니다.
Sui Discord이 커뮤니티에는 600,000명 이상의 회원이 있으며 세계에서 가장 큰 web3 커뮤니티 중 하나입니다.

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

Sui의 시스템 개체는 730만 건 이상의 스테이킹 관련 트랜잭션을 처리하여 목록에서 1위를 차지했습니다.
Frenemies game2위는 플레이 5일 만에 350만 건 이상의 거래가 완료되었습니다.
세 번째로 가장 활발한 스마트 계약은8192 game, 계약은 0x 137 aebf 47 cd 16956 b 68633 b 6 f 6 f 00 a 99 2d 87 d 9 c 6 이며 2백만 개 이상의 트랜잭션을 처리합니다.
네 번째로 가장 활발한 스마트 계약은Sui Capys, 계약은 0x 4 c 10 b 61966 a 34 d 3 bb 5 c 8 a 8 f 063 e 6 b 7445 fc 41 f 93 이며 160만 트랜잭션을 처리합니다.

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

이러한 새로운 기록과 네트워크 활동 수준을 통해 중요한 소프트웨어 업데이트를 식별하고 유효성 검사기 및 노드 운영자 커뮤니티와 협력하여 운영 능력을 향상시킬 수 있습니다.

주목할만한 웹 업데이트

웨이브 1과 유사하게 웨이브 2는 Sui의 인프라 개선 영역을 식별하는 것을 목표로 합니다.

대용량 메시지 또는 트랜잭션 처리

Wave 2는 스테이킹에 중점을 두었기 때문에 네트워크는 많은 스테이킹 및 언스테이킹 트랜잭션을 경험했으며 이는 대규모 네트워크 메시지 및 트랜잭션을 처리하는 능력을 향상시키는 데 도움이 되었습니다. 특히 보류 중인 각 스테이킹 위임 및 위임 취소 트랜잭션은 에포크 변경 중에 이벤트를 생성합니다. 이는 생성된 각 이벤트가 트랜잭션 효과의 일부이기 때문에 에포크 변경 트랜잭션의 트랜잭션 크기에 영향을 미칩니다. Wave 2에서는 한 에포크에서 최대 230,000개의 스테이킹 작업을 보았으므로 해당 에포크 변경의 트랜잭션 효과가 매우 커졌습니다.

이러한 대규모 거래는 많은 문제를 야기합니다. epoch 변경 트랜잭션 효과가 네트워크를 통해 다운로드하기에 너무 커지면 epoch 변경이 실패합니다. 트랜잭션 영향이 최대 JSON RPC 응답보다 크면 트랜잭션을 검색할 수 없습니다. 이러한 큰 트랜잭션을 로드하려고 시도하는 모든 응용 프로그램(예: Explorer)은 충돌 위험이 있습니다. 이러한 대규모 트랜잭션은 네트워크가 처리하기에는 계산 비용이 너무 많이 들 수도 있습니다. Wave 2 동안 우리 팀은 많은 양의 트랜잭션을 처리하는 동안 네트워크를 계속 실행하기 위해 몇 가지 비상 제한을 높여야 했습니다.

이에 대응하여 개체, 패키지 및 다양한 트랜잭션 데이터(입력 매개 변수, 트랜잭션 효과, 이벤트)에 대한 보호 크기 제한 추가를 가속화했습니다. 이러한 제한은 저장소, 네트워크 및 컴퓨팅 리소스가 메인넷의 대규모 교환에 의해 압도되지 않도록 하는 데 도움이 됩니다.

트랜잭션 유형 매개변수 입력의 보다 강력한 처리

2월 1일에 우리는 Move 모듈이 type 매개변수의 트랜잭션 입력으로 지정된 경우 트랜잭션 처리 로직이 Move 모듈의 종속성(예: 해당 유형이 속한 모듈이 게시되었는지 여부)을 적절하게 검증할 수 없는 버그를 발견했습니다. Move 패키지 게시는 Byzantine 합의 브로드캐스트 빠른 경로를 통해 발생하기 때문에 일부 유효성 검사기는 다른 사람보다 먼저 게시된 Move 모듈에 대해 알 수 있으며 type 매개 변수에서 이 모듈을 사용하는 트랜잭션의 유효성에 동의하지 않을 수 있습니다. 이러한 트랜잭션 중 하나는 시스템이 다음 체크포인트를 형성하지 못하도록 하여 많은 전체 노드가 정지되고 검증자가 네트워크를 분기하도록 합니다. 이것이 2월 1일 이른 시간에 Wave 2 중단의 주요 원인이었습니다.

유형 매개변수에 유효하지 않은 입력 모듈이 있는 제출된 트랜잭션이 있는 상태에서 테스트넷 실행을 유지하기 위해 우리 팀은 몇 가지 긴급 수정을 구현했습니다.

유형 매개변수의 모듈이 게시되었는지 항상 확인하십시오.
제출된 유효하지 않은 트랜잭션이 실패를 통해 실행을 완료하도록 허용합니다.
게시되지 않은 유형 매개변수를 사용하여 추가 트랜잭션 제출을 방지합니다.

그런 다음 트랜잭션 입력 확인 논리가 형식 매개 변수에 대한 입력으로 이동 모듈이 아닌 계약 삽입을 거부하지 않는 두 번째 버그를 발견했습니다. type 매개변수는 Move 모듈이어야 하므로 트랜잭션이 완료될 수 없으며 다음 체크포인트가 형성될 수 없습니다. 마찬가지로 우리 팀은 네트워크를 복원하기 위해 실행 오류로 인해 문제가 있는 트랜잭션을 강제로 실패하도록 긴급 수정을 추가해야 했습니다.

Sui의 코드베이스에 다음 두 가지 버그에 대한 수정 사항을 추가했습니다.입력 개체 생성 수정 #7940。

Narwhal 합의 메커니즘 지연 개선

Wave 1과 유사하게 Testnet Wave 2는 41개의 분산 검증자와 함께 Narwhal 합의를 추가로 테스트할 수 있는 귀중한 기회를 제공합니다. Wave 2 동안 우리는 몇 가지 합의 대기 시간 감소 최적화를 수행할 기회를 가졌습니다(두 검증자에게 병렬로 합의 커밋、병렬 인증서 확인、min_header_delay 매개변수、1초의 min_header_dela와이). 우리는 지속적으로 기능을 반복하고 있으며 곧 더 많은 기능을 제공할 예정입니다.최적화계획.

주목할만한 개발자 교훈

네트워크의 안정성을 보장하는 것이 최우선 과제이지만 장기적인 목표는 Sui를 개발자가 Sui를 기반으로 Web3.x에 대한 최고의 경험을 만들 수 있는 최고의 스마트 계약 개발자 플랫폼으로 만드는 것입니다. 이를 위해 Wave 2 동안 개발자와 사용자 마찰 지점에도 중점을 두었습니다.

토큰 관리

Wave 2 동안 여러 가지 요인으로 인해 사용자가 토큰 관리 문제에 직면할 수 있었습니다. 이러한 문제는 일반적으로 불충분한 가스 수수료 오류 또는 사용자가 거래하기에 충분한 SUI 잔액을 보유하고 있는 것처럼 보일 때 나타나는 회색 스테이크 버튼으로 나타납니다.

왜냐하면Validator Game네트워크에서 활성 상태인 기준 가스 가격은 변동될 수 있으며 각 에포크 사이에 정상보다 더 많이 증가할 수 있습니다. 높은 가스 가격 변동으로 인해 사용자가 보유한 단일 토큰의 가치가 가스 요금을 지불하기에 충분하지 않을 수 있습니다. 둘째, 초기 참조 가스 가격은 Devnet보다 높게 설정되어 사용자가 여러 토큰을 보유할 가능성이 적고 토큰이 더 빨리 소진됩니다. 마지막으로 스테이킹 작업에는 본질적으로 사용자가 기존 SUI 잔액을 하나 이상의 검증자에게 위임하는 작업이 포함됩니다. 그러나 사용자가 보유한 SUI의 레이아웃이 의도한 스테이킹 작업과 항상 일치하지 않을 수 있습니다.

이를 완화하기 위해 Wave 2 동안 몇 가지 사항을 변경했습니다.

우리를
우리를해결Sui 클라이언트가 gas_budget * gas_price 대신 gas_budget보다 큰 Gas 객체를 선택하는 SDK 버그;
Sui 지갑 스테이킹을 위한 기본 토큰 관리 추가. 그 중 각 담보 작업에 대해 paySui 트랜잭션을 사용하여 각각 담보 및 가스 결제용 모듈을 빌드합니다.
곧 지원할 예정입니다.프로그래밍 가능한 트랜잭션, 애플리케이션의 토큰 관리를 단순화합니다.