Cosmos의 Github 문서는 잘 작성되지 않았고 CosmJS 라이브러리의 많은 부분이 최적화되지 않았습니다. 제 경험은 그리 매끄럽지 않습니다.
작성자: Wuyue, Geek Web3
12월 17일에 저는 Celestia에 CIAS라는 인스크립션 있을 것이라는 것을 알고 임시로 인스크립션 브러싱하는 스크립트를 작성할 계획이었습니다. 이제 나는 Celestia와 그것이 존재하는 Cosmos 생태계는 물론 CIAS 이벤트 자체에 대해 불만이 많습니다.
사실 브러싱 인스크립션 위한 스크립트를 작성하는 것은 어렵지 않습니다. 크게 지갑 구축, 노드 연결, 범람 거래의 세 가지 모듈 로 나뉩니다. 처음 두 단계는 신속하게 구현하기 위해 대상 퍼블릭 체인의 개발자 문서에서만 찾을 수 있습니다.
먼저 Celestia 공식 홈페이지와 Github에 들어가서 살펴보았는데, 개발자를 위한 사용자 시나리오 구축에 대한 사용 사례는 없었고 주로 노드 운영과 관련된 문서 등이었습니다. 물론 Celestia는 ToC 블록체인이 아니기 때문에 이는 이해할 수 있습니다. Celestia는 눈에 띄지 않는 곳에만 Cosmos를 기반으로 하며 CosmJS를 사용하여 메인넷과 상호 작용할 수 있다고 언급했습니다.
그래서 바로 CosmJS로 갔습니다. 하지만 코스모스에 대해 뭐라고 말할 수 있을까요? 심지어 문서도 좋지 않습니다. Github에 직접 가보니 상식적으로 이런 JS는 일반적으로 Github에서 사용하는 경우가 많을 것입니다. 그러나 해당 튜토리얼은 보조 페이지에 숨겨져 있으며 클릭한 후 해당 구성을 따르고 마지막으로 오류를 보고합니다.
이 오류는 환경 문제가 아니며 해당 튜토리얼이 튜토리얼 버전으로 업데이트되지 않았기 때문에 발생합니다. 종종 이 클래스의 이름이 변경되어 조정할 수 없는 경우가 있습니다. 예전 튜토리얼 버전에서 npm 라이브러리 버전으로 전환했는데 일부 사용 사례가 여전히 작동하지 않아서 한동안 고생하다가 포기했습니다.
그래서 다시 구글링을 해보니 Github이 아닌 공식 홈페이지에 정확한 문서가 있다는 것을 알게 되었는데, 조금 무리가 있었습니다. 다시 말하지만 공식 웹사이트를 가리키도록 Github readme 튜토리얼을 업데이트하는 것이 좋지 않을까요?
올바른 튜토리얼을 받은 후 지갑 구축과 노드 연결의 두 단계를 빠르게 완료하고 플러드 거래 모듈 구축을 시작했습니다. 이 모듈 단순히 트랜잭션 서명 + 네트워크 요청을 처리하는 for 루프입니다. 그러나 여기서 우리는 몇 가지 문제에 직면합니다:
CosmJS 라이브러리의 모든 트랜잭션 메소드는 트랜잭션 자체의 매개변수만 노출하고 해당 시퀀스는 노출되지 않습니다. (시퀀스는 재생 공격을 방지하기 위해 설정된 트랜잭션 카운터인 이더 의 nonce와 유사합니다. 트랜잭션이 발행된 후 각 트랜잭션 , nonce와 시퀀스는 모두 자동으로 +1입니다.
Sequence는 실제로 서명(chainId 등) 시 네트워크에 연결하여 얻어지며, sendTokens() -> signAndBroadCast -> sign()을 거쳐야 합니다. 트랜잭션이 제출될 때마다 네트워크에 요청하고 반환을 기다리는 것은 브러싱 속도에 영향을 미치고 쓸모없는 네트워크 요청을 증가시켜 홍수에 좋지 않으며 물론 트랜잭션을 가속화/취소하는 데 도움이 되지 않습니다.
논스를 직접 지정할 수 있는 이더 Web3JS에서 트랜잭션을 보내는 방법을 검토할 수 있습니다. 하지만 CosmJS에서는 이것이 불가능합니다. 아직은 이더 의 디자인이 훨씬 더 합리적이라고 생각합니다. 논스를 직접 지정하여 트랜잭션을 취소/가속화할 수 있고, 트랜잭션이 중단된 경우 동일한 논스로 트랜잭션을 커스터마이징하여 중단된 트랜잭션을 대체할 수 있습니다. 물론 그럴 수도 있습니다. 홍수 공격에도 사용됩니다.
시간이 매우 촉박하고 라이브러리에 수정해야 할 다른 함수가 여러 개 있으므로 프록시를 사용하여 후크하고 다시 작성하지 않고 CosmJS 라이브러리에서 직접 수정하기로 결정했습니다.
플러딩 트랜잭션을 유발하는 스크립트의 아이디어는 지속적으로 트랜잭션을 시작하고 for 루프를 통해 서명을 생성하여 RPC 노드로 보내는 것입니다 . 트랜잭션을 시작한 후 시퀀스/논스는 +1이 됩니다. 20개의 트랜잭션을 시작한 후 , 사이클이 다시 반복됩니다.
시퀀스는 각 플러딩 주기가 시작되기 전에 로컬에서만 가져오며 CosmJS 라이브러리의 기본 요구 사항처럼 각 트랜잭션 후에 노드에서 시퀀스를 다시 요청할 필요가 없습니다. chainId는 고정된 값으로 작성되므로 노드를 반복적으로 요청할 필요가 없습니다. (편집자 주: 여기서 사이클 수는 상대적으로 낮게 설정되어 있으며 분명히 저자는 그다지 폭력적이지 않습니다. 누군가 Conflux 인스크립션 작성할 때 그는 한때 사이클당 사이클 수를 1000으로 변경했으며 거의 200개의 다른 트랜잭션이 매해 전송되었습니다. 분. )
마침내 간단한 Celestia 스크립트를 얻었고, CIAS가 12월 17일 밤에 네트워크 케이블을 뽑은 후 이 스크립트를 간단히 테스트하고 수백 건의 트랜잭션을 보냈습니다. CIAS가 12월 19일 이른 아침에 전투를 계속한 후 CIAS(약 1800년경)에 타격을 입혔습니다. 그러나 불평해야 할 다른 사항도 있습니다.
- 12월 17일, Celestia의 RPC 노드는 심각한 데이터 동기화 문제를 겪었습니다. 서로 다른 RPC 노드의 블록 높이가 매우 다릅니다. 노드에서 자신의 계정의 Sequence를 요청하면 기본적으로 반환된 결과가 일관되지 않습니다. 매우 고통스러운. Celestia 블록체인 익스플로러 도 사용할 수 없어 기본적으로 혼란스럽습니다. 현재 Celestia 네트워크는 다운되지 않았고 여전히 블록을 생성할 수 있지만 한계에 도달한 것으로 추정됩니다.
- 같은 날 CIAS 인스크립션 관계자는 Celestia가 더 이상 버틸 수 없음을 확인하고 블록 48460 높이 이후 체인의 모든 인스크립션 민트 거래가 유효하지 않다고 일시적으로 발표했습니다. 이는 "거래소 네트워크 케이블을 뽑는 것"과 매우 유사합니다. . 그리고 CIAS의 웹사이트도 다운되었습니다.
- 어떤 사람들은 코스모스 체인에 고유한 합의 프로토콜이 블록에 대한 합의 작업을 제대로 수행하지 못한다고 생각하고 이에 대해 언급하지 않지만 지난 밤 CIAS가 네트워크 케이블을 분리한 목적은 분명 흥미로울 것입니다.
- 12월 17일에는 거의 모든 RPC 노드가 혼잡하고 응답하지 않는 경우가 많아 가장 빠르게 데이터를 동기화하는 노드를 선택하기가 어려웠습니다. 나중에 자동으로 노드를 전환하는 코드를 작성하려고 했습니다.
- CIAS 자체의 인스크립션 형식은 다른 인스크립션 과 일치하지 않습니다.예를 들어 brc-20의 json에서는 모든 숫자가 문자열이지만 cia-20에서는 숫자입니다.
- CIAS 인스크립션 가격은 어젯밤에 최고가를 기록해 개당 1.5~2U까지 치솟았으며 심지어 인스크립션 하나를 얻기 위해 80U를 지불하는 사람도 있었습니다. 이러한 높은 처리 수수료는 제한된 TPS를 반영합니다. Celestia의 창립자는 초당 10,000건의 트랜잭션을 처리할 수 있다고 주장하는데 이는 분명히 말도 안되는 소리입니다.
종합적 으로 12월 17일 밤의 제 경험은 한 문장으로 요약할 수 있습니다. 당시 Celestia는 확실히 그 당시 대규모 트래픽을 처리하기 위한 조치를 취하지 않았으며 RPC 노드 구성에서도 매우 형식적이었습니다. 한 시간 안에 수십 개의 RPC 노드가 파괴될 수 있다고 상상해 보세요)).
19일 밤 상황은 많이 좋아졌습니다. 가스비 급등 외에는 다른 측면에서는 큰 문제가 없었습니다. 라이트 노드에 데이터를 전문적으로 배포하는 DA 네트워크인 Celestia는 일시적으로 테스트를 견뎌냈지만 앞으로 또 다른 함정이 있을지는 모르겠습니다.
