[블록체인이론] 이더리움 트랜잭션 논스 (정의, 추적, 중복문제)

트랜잭션 논스

해당 주소에서 보낸 트랜잭션 건수

또는 연결된 코드가 있는 계정의 경우, 이 계정에서 만든 컨트랙트 생성 건수와 동일한 스칼라 값

엄밀히 말하면, 논스는 발신 주소의 속성이며 단지 발신 주소의 컨텍스트 안에서만 의미를 갖는다

그러나 논스는 명시적으로 블록체인 계정 상태에 저장되지 않고,

해당 주소에서 발생한 확인된 트랙잭션 건수를 세어서 동적으로 계산되는 값이다

 

---

트랜잭션을 세는 논스의 중요성

트랜잭션 생성 순서대로 포함된다는 점에서 생기는 사용성상의 기능

: 이더리움처럼 탈중앙화된 시스템에서 노드는 어떤 순서로든 트랜잭션을 수신할 수 있기 때문에 논스가 필요하다

 

트랜잭션 복제 방지 기능

: 이더리움 네트워크에서 트랜잭션을 보는 사람은 원래 트랜잭션을 복사하여 붙여넣고 네트워크로 다시 보내는 방식으로 여러분의 이더가 소진될 때까지 계속 트랜잭션을 반복해서 '재실행'할 수 있다. 그러나 트랜잭션 데이터에 포함된 논스 값을 사용하면 각각의 개별 트랜잭션은 고유하게 된다.

 

>> 비트코인 프로토콜의 UTXO 메커니즘과 달리, 계정기반 프로토콜은 논스를 사용하는 것이 필수적이다

 

 

논스추적

논스는 각 계정에서 확인된(즉, 체인상의) 트랜잭션 건수에 대한 최신 통계다

논스 값을 알아내려면, web3 인터페이스를 통해 블록체인을 조회해야 한다

web3.eth.getTransactionCount("주소")

논스는 0부터 시작하는 카운터로, 첫 번째 트랜잭션의 논스는 0이다

새 트랜잭션을 만들 때 시퀀스상 다음 차례 논스값을 부여한다

그러나 컨펌될 때까지는 getTransactionCount 합계에 포함되지 않는다

---

논스의 간격, 중복 논스 및 확인

이더리움 네트워크는 논스에 따라 트랜잭션을 순차적으로 처리한다

 

예제 플로우 1

>> 논스가 0인 트랜잭션을 전송한 다음 다음 논스가 2인 트랜잭션을 전송하면, 두 번째 트랜잭션은 어떤 블록에도 포함되지 않게된다.

>> 이더리움 네트워크가 누락된 논스가 나타날 때까지 기다리는 동안 두 번째 트랜잭션은 멤풀에 저장된다. 모든 노드는 누락된 논스가 단순히 지연되었고 논스가 2인 트랜잭션은 순서가 맞지 않게 수신되었다고 가정한다

>> 그 다음 논스가 1인 누락된 트랜잭션을 전송하면, 두 트랜잭션 (1, 2)가 처리되고 유효한 경우 블록에 포함된다. 갭을 메우면 네트워크는 멤풀에서 보유한 순서가 잘못된 트랜잭션을 처리할 수 있다

 

=>즉 여러 트랜잭션을 순서대로 생성하고 그중 하나가 공식적으로 모든 블록에 포함되지 않으면 이후의 모든 트랜잭션이 '멈추고' 누락된 논스를 기다린다. 유효하지 않거나 가스가 모자란 트랜잭션은 논스 시퀀스에 의도치 않게 '갭'을 만들 수 있다. 다시 트랜잭션이 계속되게 하려면 누락된 논스가 있는 유효한 트랜잭션을 전송해야 한다. 누락된 논스가 있는 트랜잭션이 네트워크에 의해 유효성이 검증되면, 이후의 논스가 있는 모든 브로드캐스트된 트랜잭션이 차례대로 유효해진다는 점도 염두해야 한다. 트랜잭션을 회수하는 것은 불가능하다

 

예제 플로우 2

>> 논스가 같지만 수신자나 값이 다른 2개의 트랜잭션을 전송하는 것과 같은 논스의 중복이 일어나면,

>> 그중 하나가 확정되고 하나는 거부된다

어떤 트랜잭션이 확정되는지는 그 트랜잭션이 첫 유효 노드에 도달하는 순서에 따라 결정된다 (무작위적)

 

=> 트랜잭션을 프로그램을 통해서 생성하는 경우, 특히 여러 독립 프로세스에서 동시에 트랜잭션을 생성하는 경우에는 논스를 추적하는 것이 중요하다

 

 

---

동시 실행, 트랜잭션 생성 및 논스

동시 실행 문제

여러 독립 시스템에 의한 동시적인 계산이 있는 경우 발생

이더리움은 정의상 작업(노드, 클라이언트, 댑)의 동시 실행을 허용하지만 합의를 통해 싱클톤 상태를 강제한다

 

 

예제

동일한 주소에서 트랜잭션을 생성하는 여러 개의 독립적인 지갑 어플리케이션이 있다고 가정해보자

이러한 상황의 한 예가 거래소의 핫 월렛(키가 온라인에 저장된 지갑)에서의 출금이다

이상적으로는 병목 현상이나 단일 실패 지점이 생기지 않도록 2대 이상의 컴퓨터가 출금 작업을 처리하도록 하는 것이 좋다

그러나 이것은 문제가 될 수 있다

둘 이상의 컴퓨터에서 출금을 수행하면, 동시 실행 문제가 발생할 수 있다

물론, 논스를 선택하는 것도 중요한 문제다

동일한 핫 월렛 계정에서 여러 컴퓨터가 트랜잭션을 생성, 서명 및 브로드캐스트 하는 방식은 어떻게 조율될 수 있을까?

 

예제 플로우 1

>> 단일 컴퓨터를 이용해 트랜잭션에 서명하는 컴퓨터에 선착순으로 논스를 할당할 수 있다

그러나 이 컴퓨터는 이제 단일 실패 지점이다

더욱이, 여러 논스가 할당되고 그중 하나가 사용되지 않으면 해당 논스로 트랜잭션을 처리하는 컴퓨터 오류로 인해 모든 후속 트랜잭션이 중단된다

 

예제 플로우 2

>>트랜잭션을 생성하고 논스를 할당하지 않는 방법도 있다

이러면 트랜잭션은 서명되지 않은 상태로 남는다.

논스는 트랜잭션 데이터의 필수 부분이므로 트랜잭션을 인증하는 디지털 서명에 포함시켜야 한다

>>그런 다음, 이 서명되지 않은 논스를 관리하는 작업은 시스템 부하가 늘어남에 따라 혼잡해질 수 있지만,

서명되지 않은 트랜잭션들을 생성하는 작업은 병렬 처리 문제를 고민하지 않아도 된다

여전히 동시 실행 문제가 남아 있기는 하지만, 크리티컬한 프로세스 부분에서는 더 이상 존재하지 않게 된다

 

결론

이러한 동시 실행 문제는 각각의 독립적인 프로세스들이 어카운트 밸런스를 추적하고 트랜잭션을 컨펌해야 하는 어려움이 가중된다.

따라서 대부분의 구현 솔루션들이 동시 실행을 피하고 거래소에서 출금 트랜잭션을 처리하는 단일 프로세스를 만드는 것처럼 병목지점을 어쩔 수 없이 받아들이거나,

독립적으로 작동하는 다수의 출금 핫 월렛을 설치하고 중간중간에 각 지갑의 밸런스를 다시 채워주는 형식으로 해결하게끔 만든다