For the complete documentation index, see llms.txt

Decode 1010 transaction rejection errors

1010 Invalid Transaction 응답이 발생했을 때, 내부의 Custom error: N 값을 Midnight ledger 오류 변형으로 디코딩하여 문제를 해결하세요.

Understand the cause of the error

Midnight 노드에 트랜잭션을 제출하면 JSON-RPC 계층이 다음과 같이 코드 1010으로 거부할 수 있습니다.

{
  "code": 1010,
  "message": "Invalid Transaction",
  "data": "Custom error: 155"
}

코드 1010 자체는 Substrate의 외피이며, Midnight 고유의 오류가 아닙니다. 노드의 트랜잭션 풀이 extrinsic을 거부했음을 알리는 신호일 뿐입니다. 실제로 의미 있는 정보는 Custom error: N의 N 값으로, 이는 Midnight 노드가 정의한 LedgerApiError 변형에 대응하는 u8(0–255) 값입니다.

Two layers, one error

1010은 Substrate에서 상속된 코드이고, 내부의 u8이 Midnight의 코드입니다. 문제를 진단하려면 이 u8 값을 디코딩해야 합니다.

Extract the inner u8

내부 u8 값은 RPC 오류 응답의 data 필드 안에 들어 있습니다. 일반적인 클라이언트 환경에서 이 값을 추출하는 방법은 아래 단계를 참고하세요.

1

Capture the full RPC response

메시지 문자열만이 아니라 전체 오류 응답을 그대로 받아야 합니다. 많은 지갑 라이브러리와 CLI 래퍼는 기본적으로 data 필드를 잘라냅니다.

JavaScript

try {
  await wallet.submitTransaction(tx);
} catch (err) {
  console.error(String(err));
}

wallet은 WalletFacade이고 tx는 완결된 트랜잭션입니다. String(err)는 전체 오류 체인을 출력하며, 그 끝에 노드의 응답이 담깁니다. 예를 들어 RpcError: 1010: Invalid Transaction: Custom error: 155처럼 나타납니다. err.message에는 바깥쪽 Transaction submission error만 담기고, JSON.stringify(err)는 노드가 보낸 텍스트를 빠뜨립니다. 여러분의 코드와 노드 사이에 끼어 있는 래퍼 목록은 Transaction submission errors를 참고하세요.

cURL

curl -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"author_submitExtrinsic","params":["0x..."]}' \
  http://localhost:9944

2

Read the trailing integer in the data field

data 필드는 Custom error: N 형태로 끝나며, 여기서 N이 변형 코드입니다.

"data": "Custom error: 155"

이 예시에서 N은 155입니다.

3

Look up the variant

Node error codes 페이지의 오류 테이블에서 u8 값을 찾으세요. 테이블은 코드를 범위별로 묶어 두었고, 각 행은 변형 이름, 설명, 해결 방법을 알려줍니다.

Variant codes change between releases

변형 번호는 Midnight 노드가 정의하며 릴리스마다 달라질 수 있습니다. 오류 테이블은 노드 버전 1.0.x 기준의 코드를 담고 있습니다. 사용 중인 네트워크의 노드 버전에 맞는 릴리스 노트를 항상 함께 확인하세요.

Common causes and fixes

다음 변형들은 1010 오류의 흔한 원인입니다.

168 FeeCalculation / 155 FeeCalculationError: 제출된 트랜잭션의 수수료 계산이 실패한 경우

ledger가 수수료를 계산하지 못하는 경우는 두 가지입니다:

• 트랜잭션의 어느 비용 차원이 해당 블록 한도를 넘는 경우.
• 트랜잭션을 검증하고 보장 부분을 적용하는 데, 그 크기의 트랜잭션에 ledger가 허용하는 시간보다 더 오래 걸리는 경우.

작업을 더 작은 트랜잭션으로 나누세요. 수수료를 적게 낸다고 이 코드가 발생하지는 않습니다. 수수료보다 적게 내는 트랜잭션은 노드가 138 BalanceCheckOverspend로 거부합니다.

154 BlockLimitExceededError: 트랜잭션이 블록 리소스 한도를 초과하는 경우

트랜잭션에 포함된 인텐트, 호출 등의 개수를 줄이세요. 배치 작업이라면 여러 트랜잭션으로 나누어 실행하세요.

108 ReplayCounterMismatch / 193 ReplayProtectionViolation: replay protection이 트랜잭션을 거부한 경우

108은 컨트랙트 maintenance 업데이트의 카운터가 컨트랙트의 현재 maintenance 카운터와 일치하지 않는다는 뜻입니다. 컨트랙트의 현재 상태를 읽어 업데이트를 새로 만드세요. 193은 ledger가 동일한 인텐트를 이미 적용했다는 뜻이므로, 이미 블록에 들어가 있을 수 있는 트랜잭션을 다시 제출하지 마세요. TTL이 지난 뒤 도착하거나 TTL이 너무 먼 미래인 트랜잭션은 노드가 182 TransactionApplicationError로 거부합니다.

115 InvalidProof: 영지식 증명 검증에 실패한 경우

proof server가 노드 및 SDK와 호환되는 버전으로 실행 중인지 확인하세요. proof server 실행과 릴리스 호환성 매트릭스를 참조하세요.

166 InvalidNetworkId: 트랜잭션이 다른 네트워크용으로 만들어진 경우

SDK와 지갑이 트랜잭션을 제출하려는 노드와 같은 네트워크 ID로 설정되어 있는지 확인하세요. 예를 들어 preprod 노드는 네트워크 ID preview로 만든 트랜잭션을 거부합니다.

126 Unbalanced / 138 BalanceCheckOverspend: 트랜잭션의 입력과 출력 균형이 맞지 않는 경우

지갑이 보유 코인 집합으로 감당할 수 없는 양을 지출하려 했거나, 잔돈 출력을 잘못 계산한 경우입니다. 지갑을 다시 동기화한 뒤 트랜잭션을 새로 만드세요.

When 1010 has no inner u8

응답에 code: 1010은 있지만 Custom error: N 부분이 없다면, Midnight ledger가 아니라 Substrate 검사가 트랜잭션을 거부한 것입니다. Midnight 트랜잭션은 서명 없는 send_mn_transaction 호출로 노드에 도달하며, 노드는 이를 validate_unsigned에서 검사합니다. 잘못될 수 있는 서명자, nonce, mortal era 자체가 없습니다. 실제로 마주치기 쉬운 경우는 한 블록에 담기에 너무 무거운 트랜잭션입니다.

1010: Invalid Transaction: Transaction would exhaust the block limits

Substrate의 weight 검사는 트랜잭션이 ledger 검사는 통과했지만 노드가 단일 트랜잭션에 허용하는 것보다 블록을 더 많이 필요로 할 때 이 응답을 돌려줍니다. 흔한 원인은 export된 circuit이 많은 컨트랙트 배포입니다. 배포 시 circuit마다 verifier key가 하나씩 함께 실리기 때문입니다. 우선 들어맞는 만큼의 circuit으로 컨트랙트를 배포한 뒤, 나머지 verifier key는 서명된 maintenance 업데이트로 추가하세요. 배치 배포 런북이 이 과정을 안내합니다.

이 거부는 ledger에 도달하지 않으므로 오류 테이블에 나타나지 않습니다.

때로는 1010 자체가 전혀 없고 TransactionInvalidError: Transaction is invalid and was rejected by the node만 나오기도 합니다. 이 경우 노드가 트랜잭션을 풀에 받아들였다가 나중에, 예를 들어 블록을 생성하는 도중에 버린 것입니다. Submission error messages를 참고하세요.

Verify the fix

해당 변형을 식별해 조치한 뒤, 트랜잭션을 다시 제출하여 노드가 받아들이는지 확인하세요.

# Re-submit and observe the response
curl -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"author_submitExtrinsic","params":["0x..."]}' \
  http://localhost:9944

제출이 성공하면 오류 외피 대신 트랜잭션 해시가 반환됩니다.

Get help

변형을 식별하지 못하거나, 위 조치를 적용한 뒤에도 거부가 계속된다면 다음을 확인하세요.

• Confirm the node version: 변형 번호는 릴리스에 따라 달라집니다. 사용 중인 네트워크의 버전에 해당하는 노드 릴리스 노트를 확인하세요.
• Check the compatibility matrix: proof server, 런타임, SDK가 릴리스 호환성 매트릭스에서 지원하는 조합과 일치하는지 확인하세요.