토큰 전송 흐름
이전 글에서 우리는 서로 다른 샤드에 있는 계정 간 토큰 전송의 예를 보았습니다. 이 예는 단순화되었으며 프로세스의 몇 단계가 누락되었습니다. 개념을 이해하기 위한 더 큰 그림을 제공하기 위해, 기사와 비디오를 일부러 짧지만 설명적으로 구성하였기 때문입니다.
이 글에서는 동일한 데이터 흐름을 살펴보지만, 더 자세히 살펴본 뒤 두 가지 추가 시나리오를 고려할 것입니다.
- 다른 샤드에 있는 계정 간 토큰 전송
- 동일한 샤드에 있는 계정 간 토큰 전송
이전 설명에서 누락된 것이 무엇인지 물을 수 있습니다. 짧은 대답은 가스 환불 또는 간단히 환불 입니다.
If you don't know what Gas is, please first read the article about Gas from our docs.
As for Refunds, here's a quote from the Gas article:
여분의 가스는 환불됩니다!
...
- 필요한 것보다 더 많은 가스를 포함하면 환불됩니다.
...
From NEAR Protocol docs Gas. 여분의 가스는 환불됩니다!에서
말 그대로 모든 트랜잭션에 환불이 포함된다는 의미입니다.
좋습니다, 이제 소개하기에 충분합니다. 이제 예제로 이동하겠습니다.
다른 샤드에 있는 계정 간 토큰 전송
기본적으로 NEAR 데이터 흐름 글의 예제를 확장한 것입니다.
두 개의 계정 alice.near 및 bob.near가 있다고 가정해봅시다. They belong to different Shards. alice.near는 bob.near에 몇 개의 토큰을 보냅니다.
A Transaction signed by alice.near is sent to the network. It is immediately executed, ExecutionOutcome is the output or result from converting the transaction into a Receipt.
위의 과정 에서 발신자 alice.near에게 수수료(가스)가 부과되었습니다. The Receipt created as result of the Transaction follows these rules:
So, in our case the receiver is bob.near and that account belongs to a different Shard that's why the Receipt moves to the receiver's Shard and is put in the execution queue.
이 예제에서 Receipt는 바로 다음 블록에서 실행됩니다.
거의 끝났습니다. 환불을 기억하시나요? 이제 alice.near는 새(그리고 마지막) Receipt의 수신자가 됩니다(이 Receipt의 발신자는 항상 시스템임을 명심하세요). So the ExecutionOutcome for the Receipt will be another Receipt that is refunding the Gas to the sender. bob.near는 alice.near로부터 토큰을 받았습니다.
규칙 #2를 명심하세요: Receipt는 수신자의 샤드에서 실행되어야 합니다. 따라서 이 Receipt는 alice.near가 속한 샤드로 이동합니다. 그리고 이는 전체 과정에서 마지막 실행입니다.
이제 끝났습니다. Tokens have been transferred from the account on one Shard to the account on a different Shard, and the initial sender, alice.near, received a refund of Gas.
동일한 샤드에 있는 계정 간 토큰 전송
Let's have a look at the example where both accounts are on the same Shard. 프로세스는 한 샤드에서 다른 샤드로 이동하는 Receipt가 없다는 점을 제외하면 이전 예제와 동일합니다.
A Transaction signed by alice.near is sent to the network. It is immediately executed, ExecutionOutcome is the result of converting the transaction into a Receipt.
It is executed in the next Block, and the ExecutionOutcome result is a new Receipt with the refund to the initial sender, alice.near. 동일한 규칙이 이 Receipt에 적용되며 실행 대기열에 넣어지고 다음 블록에서 실행됩니다. The Receipt is already on the receiver's Shard, so it is put in the execution queue of the next Block.
이제 끝났습니다. 동일한 샤드 예제에 대해 프로세스가 지나치게 복잡한 이유가 궁금할 수 있습니다. 답은 항상 동일한 규칙이 적용된다는 것입니다. 또한 이 메커니즘을 사용하면 얼마나 많은 샤드가 존재하는지에 관계없이 단 하나의 규약으로 NEAR 프로토콜 데이터 흐름을 구축할 수 있습니다. 또한 프로세스가 항상 동 일한 규칙을 따르기 때문에, 우리는 많은 "if"를 피할 수 있고, 별도의 코너 케이스를 염두에 둘 필요가 없습니다.
