트랜잭션
NEAR는 설계상 비동기식입니다. 이는 스마트 컨트랙트 구현을 위한 광범위한 가능성을 열어주지만, 다른 블록체인 플랫폼을 사용하던 사람들에게는 혼란을 가중할 수도 있습니다. NEAR의 트랜잭션에는 비동기 작업을 수행하는 작업이 포함될 수 있습니다. 이러한 경우 트랜잭션의 가능한 결과(성공 or 실패)를 염두에 두십시오. 예를 들어 트랜잭션에 교차 컨트랙트 호출이 포함된 경우, 성공으로 표시될 수 있지만 다른 컨트랙트 실행은 실패할 수 있습니다. 이 문서에서는 이에 대한 가능한 시나리오를 다룹니다.
트랜잭션은 네트워크에 할당할 수 있는 가장 작은 작업 단위입니다. 여기서 "작업"은 컴퓨팅(함수 실행) 또는 저장(데이터 읽기/쓰기)을 의미합니다. 트랜잭션은 하나 이상의 Actions로 구성됩니다. 둘 이상의 작업이 있는 트랜잭션을 "배치 트랜잭션"이라고 합니다. 트랜잭션은 가장 작은 작업 단위이므로 원자성을 가지고 있지만, 비동기 작업이 반드시 전체 트랜잭션의 성공 또는 실패를 계단식으로 나열하는 것은 아닙니다.
Receipt라는 개념도 있습니다. 이는 "Action을 적용하기 위한 요청"이거나, "Action의 결과"입니다. 모든 교차 컨트랙트 커뮤니케이션은 Receipt를 통해 이루어집니다. 작업으로 인해 하나 이상의 Receipt가 생성될 수 있습니다. 블록체인은 일련의 트랜잭션으로 보일 수 있지만 일련의 Receipt이기도 합니다.
트랜잭션에 대한 자세한 문서는 NEAR 프로토콜 사양 (nomicon.io)에서 찾을 수 있습니다. 이 페이지에서는 NEAR 트랜잭션의 중요한 측면에 대한 개요를 제공합니다.
트랜잭션
Transaction은 목적지(receiver 계정)에서 수행되어야 하는 것들을 묘사하는 Actions의 집합입니다.
각 Transaction은 다음과 같은 중요한 정보들을 담고 있습니다:
- 출처 (
signer에 의해 암호화 서명됨) - 목적지 또는 의도 (
receiver에게 전달되어 적용됨) - 최신성 (허용가능한 한도 - 1 epoch - 내 최신 블록으로부터의
block_hash) - 고유성 (주어진
signer와AccessKey에 대해 고유한nonce를 가짐)
Action
Action은 0개 이상의 다른 Action과 함께 Transaction을 정의하는 구성 가능한 작업 단위입니다. 현재는 8 종류의 Action이 존재합니다.
FunctionCall은 컨트랙트에서 메서드를 호출하고 선택적으로 컴퓨팅 및 스토리지에 필요한 수수료를 포함합니다.Transfer는 계정 간 토큰을 이동시킵니다.DeployContract는 컨트랙트를 배포할 때 사용됩니다.CreateAccount는 새로운 계정을 만들 때 사용됩니다.DeleteAccount는 계정을 삭제하고 수혜자 계정으로 잔고를 이동합니다.AddKey는 계정에 키(FullAccess또는FunctionCall접근권)를 추가합니다.DeleteKey는 계정에서 기존 키를 삭제합니다.Stake는 다음 기회에 밸리데이터가 되는 것에 대한 관심을 표명할 때 사용됩니다.
NEAR nomicon에서 Action들의 기술적 세부 사항에 대해 자세히 알아볼 수 있습니다 .
Receipt
Receipt는 시스템에서 실행 가능한 유일한 개체입니다. 따라서 NEAR 플랫폼에서 "트랜잭션 처리"에 대해 이야기하는 것은, 결국 어느 시점에서의 "Receipt를 적용"하는 것을 의미합니다.
간단하게 Receipt를 목적지(receiver)에서 실행되는 유료 메세지로 생각할 수 있습니다. 그렇다면 Transaction은 Receipt를 생성하기 위해 외부에서 발행된 요청 정도로 생각할 수 있겠죠(1대1 관계).
Receipts를 만드는 방법에는 여러 가지가 있습니다:
Transaction발행- 약속 반환 (교차 컨트랙트 호출 관련)
- 환불
NEAR nomicon에서 Receipt들의 기술적 세부 사항에 대해 자세히 알아볼 수 있습니다.
트랜잭션 원자성
트랜잭션은 적용되기 전에 Receipt로 변환되기 때문에, Receipt 원자성에 대해 이야기하는 것으로도 충분할 것입니다. Receipt 실행은 원자적입니다. 즉, 모든 작업이 성공적으로 실행되거나 아무 작업도 실행되지 않음을 의미합니다. 그러나 한 가지 주의할 점은 함수 호출 트랜잭션은 다른 트랜잭션과 달리 무한한 양의 Receipt를 생성할 수 있으며, 각 Receipt는 원자적이지만 하나의 Receipt의 성공 또는 실패가 동일한 트랜잭션에 의해 생성된 다른 Receipt의 상태에 반드시 영향을 미치지는 않는다는 것입니다.
스마트 컨트랙트를 설계할 때 NEAR 프로토콜의 비동기적 특성을 항상 고려해야 합니다.
트랜잭션 상태
RPC API를 통해 트랜잭션 상태를 조회할 수 있습니다 . 조회 결과의 예는 다음과 같습니다.
{
"status": { "SuccessValue": "" },
"transaction": {
"actions": [
{ "Transfer": { "deposit": "50000000000000000000000000" } }
],
"hash": "EL9cEcoiF1ThH1HXrdE5LBuJKzSe6dRr7tia61fohPrP",
"nonce": 51,
"public_key": "ed25519:5zset1JX4qp4PcR3N9KDSY6ATdgkrbBW5wFBGWC4ZjnU",
"receiver_id": "transfer-vote.near",
"signature": "ed25519:37rcwcjDBWWAaaRYCazHY72sfDbmudYvtmEBHMFmhYEfWD3mbrgrtYs5nVh9gzRUESELRDET9g72LnAD2BWdSgKu",
"signer_id": "near"
},
"transaction_outcome": {
"block_hash": "dvwSabiWzRjfQamZCEMeguxxXL4885JGU87xfjoPWR2",
"id": "EL9cEcoiF1ThH1HXrdE5LBuJKzSe6dRr7tia61fohPrP",
"outcome": {
"executor_id": "near",
"gas_burnt": 223182562500,
"logs": [],
"metadata": { "gas_profile": null, "version": 1 },
"receipt_ids": [
"6LrHPazG3DTcKkd4TjqbgajqmbcAfyoTG383Cft5SZ5Y"
],
"status": {
"SuccessReceiptId": "6LrHPazG3DTcKkd4TjqbgajqmbcAfyoTG383Cft5SZ5Y"
},
"tokens_burnt": "22318256250000000000"
},
"proof": []
},
"receipts_outcome": [
{
"block_hash": "6evPKFQRw1E3gH9L1d59mz7GahsbnqsdYwcZQo8hpFQB",
"id": "6LrHPazG3DTcKkd4TjqbgajqmbcAfyoTG383Cft5SZ5Y",
"outcome": {
"executor_id": "transfer-vote.near",
"gas_burnt": 223182562500,
"logs": [],
"metadata": { "gas_profile": null, "version": 1 },
"receipt_ids": [
"7NMpF9ZGwSj48bpvJK2xVobJkTasEkakazTKi2zotHR4"
],
"status": { "SuccessValue": "" },
"tokens_burnt": "22318256250000000000"
},
"proof": []
},
{
"block_hash": "Gm6TFS1ZxmA45itVj8a7vE8yJF8V5hXeNF1EhEVr7GVS",
"id": "7NMpF9ZGwSj48bpvJK2xVobJkTasEkakazTKi2zotHR4",
"outcome": {
"executor_id": "near",
"gas_burnt": 0,
"logs": [],
"metadata": { "gas_profile": null, "version": 1 },
"receipt_ids": [],
"status": { "SuccessValue": "" },
"tokens_burnt": "0"
},
"proof": []
}
]
}
조회 결과는 다음을 표시합니다.
- 트랜잭션의 전반적인 상태
- 트랜잭션의 결과
- 이 트랜잭션에 의해 생성된 Receipt의 결과.
status 필드는 다음에 나타납니다:
- 최상위 레벨: 트랜잭션의 모든 작업이 성공적으로 실행되었는지 여부를 나타냅니다.
-
transaction_outcome: 거래가 성공적으로 Receipt으로 전환되었는지 여부를 나타냅니다. - 각 Receipt에 대한
receipts_outcome: Receipt가 성공적으로 실행되었는지 여부를 나타냅니다.
status는 다음 4개 중 하나의 키가 있는 객체입니다.
status: { SuccessValue: 'val or empty'}- Receipt 또는 트랜잭션이 성공적으로 실행되었음을 나타냅니다. 함수 호출 Receipt의 결과인 경우 값은 함수의 반환 값이고, 그렇지 않은 경우 값은 비어 있습니다.status: { SuccessReceiptId: 'id_of_generated_receipt' }- 트랜잭션이 성공적으로 Receipt로 변환되었거나 Receipt가 성공적으로 처리되어 다른 Receipt가 생성되었음을 나타냅니다. 이 키의 값은 새로 생성된 Receipt의 ID입니다.status: { Failure: {} }'- 실행 중인 트랜잭션 또는 Receipt가 실패했음을 나타냅니다. 값에는 오류 이유가 포함됩니다.status: { Unknown: '' }'- 트랜잭션 또는 Receipt가 아직 처리되지 않았음을 나타냅니다.
Receipt의 경우, SuccessValue와 SuccessReceiptId는 마지막 Action 실행에서 가져옵니다. 동일한 Receipt의 다른 작업 실행 결과는 반환되지 않습니다. 그러나 Action이 실패하면, Receipt 실행이 중지되고 status에 Failure가 반환됩니다. 마지막 Action이 함수 호출이 아니고 성공적으로 실행되면, 결과는 빈 SuccessValue일 것입니다.
최상위 레벨 status는 트랜잭션의 모든 작업이 성공적으로 실행되었는지 여부를 나타냅니다. 그러나 한 가지 주의할 점은 함수 호출을 성공적으로 실행했다고 해서 반드시 함수 호출에서 생성된 Receipt가 모두 성공적으로 실행되는 것은 아니라는 점입니다.
예를 들어:
pub fn transfer(receiver_id: String) {
Promise::new(receiver_id).transfer(10);
}
이 함수는 약속을 예약하지만, 반환 값은 해당 약속과 관련이 없습니다. 따라서 약속이 실패하더라도 잠재적으로 receiver_id가 존재하지 않기 때문에, 이 함수를 호출하는 트랜잭션은 여전히 전체 status에 SuccessValue를 가지고 있을 것입니다. 동일한 조회 결과를 통해 생성된 각 Receipt의 상태를 확인할 수 있습니다.
완결성
트랜잭션 완결성은 트랜잭션이 포함된 블록의 완결성과 밀접하게 연결되어 있습니다. 그러나 대부분의 Action이 Receipt 실행에서 이루어지기 때문에, 트랜잭션 자체가 아닌 Receipt가 완결되었는지 여부에 관심이 있는 경우가 많습니다. 즉, 모든 경우에 이것이 동일하지는 않습니다. 따라서 트랜잭션의 완결성을 검증하기 위해서는 트랜잭션을 조회해서 트랜잭션의 모든 블록해시와 트랜잭션에서 생성된 Receipt가 완결되었는지 확인할 수 있습니다.