출근하면서 간단하게 읽어보는 수이가 멈춘 이유.

1. 일단 네트워크 수요가 많아서 발생한 사건은 아님. (이게 제일 좋은 케이스지만 아쉽게도 아니었음)

2. 일단 이 사태를 이해하려면, 수이의 혼잡 제어 시스템(congestion control)에 대한 이해가 필요함. 수이는 객체 기반의 스토리지를 사용하기 때문에 트랜잭션이 건드리는 객체간에 연관성이 크게 없다면 트랜잭션들을 병렬처리 할 수 있는 특징을 가지고 있음. 하지만 트랜잭션들이 하나의 공유 객체와 관련되었다면(예를 들어서 여러 사람이 같은 NFT를 구매하려고 한다던지), 이들을 병렬처리 할 수 없음.

3. 순차처리가 필요한 트랜잭션들이 몰리게 되었을 때 시스템 과부하를 막기 위해서 혼잡 제어 시스템이라는 것을 만든 것임.

4. 여기서 중요한데, 최근에 수이는 성능 개선을 위해서 혼잡 제어 시스템을 업그레이드 하였는데, 이 “TotalGasBudgetWithCap” 모드에서 트랜잭션 복잡도를 계산하여 실행비용을 계산 하였는데 그 결과가 0이 나왔고, 코드에 있던 assert! 구문이 실행 비용이 0이면 안된다는 판단을 내려서 시스템 충돌이 발생했다고 함.

5. 그럼 왜 실행비용이 0이 나왔냐. 아마 이번 트랜잭션이 변경 가능한 공유 객체에 접근했지만 MoveCall이 없는 특이한 형태라서 비용을 0으로 계산하지 않았나 싶음. 이번 트랜잭션은 공유 객체에 접근하는 트랜잭션이라서 그 자체만으로도 비용이 발생해야 하지만 새로운 모드에서 그 비용을 0으로 계산한 것이고, 시스템은 이게 말이 안된다고 판단하고 충돌을 일으킨 것.