시스템 트랜잭션
EVM 애플리케이션은 eth_getLogs와 같은 표준 인터페이스를 통해 온체인 활동을 구독합니다. 그러나 Stable에서 가장 중요한 작업 중 일부(예: 스테이킹 언본딩 완료)는 EVM 이벤트를 자연스럽게 방출하지 않는 SDK 모듈 내에서 발생합니다. 시스템 트랜잭션은 이러한 가시성 격차를 해소합니다. 프로토콜 자체는 SDK 계층 작업에 대한 이벤트를 방출하는 EVM 트랜잭션을 제출하여 dApp이 이미 사용하는 동일한 로그 스트림을 통해 인덱싱할 수 있게 합니다.
이것이 중요한 이유
사용자의 토큰이 언제 언본딩을 완료하는지 추적하는 것을 생각해 봅시다. 시스템 트랜잭션이 없다면, dApp은 다음 중 하나를 해야 합니다.
- SDK 이벤트를 감시하고 자체 데이터베이스에 저장하는 별도의 인덱서를 실행합니다. 운영 오버헤드와 새로운 실패 지점이 발생합니다.
- REST 엔드포인트를 주기적으로 폴링합니다. 5–10초 지연, 더 높은 RPC 부하, 유지보수해야 할 두 가지 클라이언트 스택(web3 + REST)이 발생합니다.
시스템 트랜잭션은 dApp에 EVM 로그에 이미 사용하는 동일한 WebSocket 연결을 통해 실시간 이벤트 알림을 제공합니다. 별도의 인덱서가 필요 없고, REST 폴링도 필요 없습니다.
작동 방식
1. 프로토콜 이벤트: SDK 계층 작업이 완료됩니다(예: 스테이킹 언본딩).
2. 감지: x/stable EndBlocker는 이벤트를 감지하고 상태에 대기시킵니다.
3. 시스템 TX: 다음 블록의 PrepareProposal에서 프로토콜은 StableSystem 사전 컴파일러를
호출하는 시스템 트랜잭션을 생성합니다.
4. EVM 방출: 사전 컴파일러는 대기 중인 항목을 처리하고 표준
EVM 이벤트를 방출합니다. dApp은 eth_getLogs 및 구독을 통해 이를 확인합니다.시스템 트랜잭션은 사용자가 아닌 블록 제안 중에 검증자가 생성합니다. 사용자 트랜잭션보다 먼저 블록의 맨 앞에 착륙합니다.
StableSystem 사전 컴파일러
이벤트는 0x0000000000000000000000000000000000009999의 StableSystem 사전 컴파일러를 통해 흐릅니다. 현재 스테이킹 언본딩에 대해 하나의 이벤트(UnbondingCompleted)를 방출합니다. 프로토콜은 동일한 패턴으로 다른 SDK 작업(검증자 수수료 변경, 거버넌스 실행)으로 확장하도록 설계되었습니다.
보안 모델
두 가지 속성은 이벤트 스트림의 신뢰성을 유지합니다.
- 프로토콜 전용 발신자. 시스템 트랜잭션은
0x8888888888888888888888888888888888888888를 발신자로 사용합니다. EVM 상태 전환 규칙은 이 주소에서StableSystem사전 컴파일러로의 트랜잭션만 서명 검증을 건너뛸 수 있도록 허용합니다. 사용자는 자신의 트랜잭션에서 이벤트를 위조하거나 제한된 사전 컴파일러 함수를 호출할 수 없습니다. - 결정론적 방출. 모든 정직한 검증자는 동일한 프로토콜 이벤트에 대해 동일한 시스템 트랜잭션을 생성합니다. 표준 합의 외에 추가적인 신뢰 가정은 없습니다.
배치 처리
블록 크기를 제한하기 위해 각 블록은 최대 100개의 언본딩 완료를 처리합니다. Stable의 ~700ms 블록 시간에서 이는 분당 약 9,000개의 완료를 의미하며, 이는 일반적인 스테이킹 활동보다 훨씬 높습니다. 버스트가 블록당 제한을 초과하면 완료는 FIFO 순서로 대기열에 추가되고 후속 블록에 걸쳐 처리됩니다.
SDK 이벤트와 EVM 방출 사이에는 한 블록(~700ms)의 지연이 있는데, 이는 7일 언본딩 기간 자체에 비해 무시할 수 있는 수준입니다.
ABI를 찾는 곳
StableSystem 인터페이스, 이벤트 서명 및 발신자 권한 부여 규칙은 시스템 트랜잭션 참조에 있습니다.
다음 권장 사항
- 시스템 트랜잭션 참조:
IStableSystem인터페이스, 가스 계산 및 권한 부여 규칙을 검토하세요. - 스테이킹 모듈: 시스템 트랜잭션 이벤트로 나타나는 SDK 작업을 확인하세요.
- 시스템 모듈 개요: 사전 컴파일러가 노출하는 모듈 목록으로 돌아갑니다.

