왜 USDT 전송 집계가 필요하나요?
대규모 USDT 사용을 지원하는 데 있어 핵심 과제는 처리량과 공정성을 동시에 최적화하는 것입니다:- 기존 ERC20 토큰 전송은 순차적으로 처리되므로, 높은 트랜잭션 부하 시 병목 현상이 발생합니다.
- 단순히 USDT0의 처리량을 우선시하면, 다른 트랜잭션이 밀려나 체인 전반의 성능이 저하될 수 있습니다.
병렬 집계 및 검증
여기서 설명하는 내용은 현재 전략을 바탕으로 한 미래 지향적인 계획입니다. 모든 로드맵 항목과 마찬가지로, 더 많은 인사이트를 확보하고 새로운 우선순위에 따라 업데이트될 수 있습니다.전송 집계 시스템의 핵심은
MapReduce 컴퓨팅 모델에서 영감을 받은 병렬 가능한 집계 및 검증 파이프라인입니다. 각 전송을 순차적으로 처리하는 대신, 시스템은 번들 단위로 연산을 수행하며, 계정 간 입출금을 집계한 후 잔액 업데이트를 실행합니다.
주요 단계
- 계정 diff 집계
- 각 전송은 송신자와 수신자에 매핑됩니다.
- 각 계정에 대해 토큰 이동의 순 변화(net movement)를 나타내는 diff 저널이 생성됩니다:
- 총 차감액(보냄): 음수 값
- 총 수신액(받음): 양수 값
- 잔고 검증
- 시스템은 전체 입력과 출력이 일치하는, 글로벌 잔액 불변성을 보장합니다.
- 각 계정의 순 변화는 병렬로 독립적으로 검증되어 잔액이 충분한지 확인됩니다.
- 잔액이 부족한 계정이 있어도 번들 실행을 멈추지 않고, 해당 계정을 별도로 표시합니다.
- 병렬을 위한 MapReduce 모델
- Map 단계: 모든 입출금 전송을 기반으로 각 계정의 순 델타(net delta)를 계산합니다.
- Reduce 단계: 이 델타들을 집계하여 최종 상태 업데이트를 결정합니다.
기술적 하이라이트
병렬 계산 모델
- 프리컴파일 컨트랙트 내 병렬성을 활용하여 잔액 확인 및 diff 연산을 동시에 수행합니다.
- 기존의 순차적 ERC20 처리 대비 실행 시간을 대폭 단축할 수 있습니다.
의존성 분석
- 중복 전송(예: 동일 계정에서 다수 전송)을 식별합니다.
- 실패 가능성이 높은 전송(예: 잔액 부족 예상됨)을 사전 표시하여 연쇄적인 실패를 방지합니다.
모듈식 실패 핸들링
- 전송은 계정 단위로 격리되므로, 문제가 있는 계정만 영향을 받습니다.
- 충돌 없는 전송은 정상적으로 실행 및 완료됩니다.
선택적 실패 처리
- 기존의 블록 내 전송 처리 방식은 성공 또는 실패 중 하나의 전체 처리 방식이었으나, Stable의 집계 모델은 계정별 실패 격리를 도입합니다:
- 특정 계정이
현재 잔액 + 순 변화 < 0인 경우, 해당 계정의 전송만 실패로 처리합니다. - 다른 계정이 포함된 전송은 정상적으로 진행됩니다.
- 이 선택적 롤백 메커니즘은, 잘못된 전송이나 악의적 전송이 전체 번들의 무결성을 해치지 않도록 보장합니다.
- 특정 계정이
프로포저 혹은 평판 기반 정렬
실행 최적화 및 상태 충돌 방지를 위해, Stable은 집계된 전송에 대해 사전 처리 순서 지정 메커니즘을 도입합니다:- 평판 기반 정렬: 신뢰도 높은 이력 또는 검증된 신원을 가진 송신자는 우선 처리되어 실패 및 재정렬 위험이 줄어듭니다.
- 프로포저 기반 정렬: 신뢰할 수 있는 프로포저 노드가 트랜잭션을 정렬하여 충돌을 최소화하고 처리량을 극대화합니다.
- 전송 번들 우선 처리: 집계된 USDT 전송은 일반 트랜잭션보다 우선 순위로 처리되어 의존성 충돌을 줄이고 깔끔한 실행 윈도우를 확보됩니다.

