IOTA 트랜잭션, 확정 및 합의

IOTA Donations: QPLGOG9PMIMUAW9UDMUNZQHPXZPXDNGLBEIHILXHWHIOFHLIHPDDERXAJQKUQDEORMHSUWVZQE9JYSHIWADIIPAOJD

<blockquote> <p dir="auto">IOTA Donations for Korean version: RLNVZQOKBZRUNZUHDLNMW9XVRVTOBMNLZKXBW9PYMBCOGPCVAEMNUESFD9OGCZVILOACELXGXHIWSXWYCDMXXHNIUX <h1>IOTA 트랜잭션, 확정 및 합의 <p dir="auto"><span>이 글은 <a href="https://github.com/noneymous/iota-consensus-presentation/blob/master/README.md" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://github.com/noneymous/iota-consensus-presentation/blob/master/README.md 를 원저자의 허락을 받고 번역한 글입니다. <h2>탱글 초기 상태 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/xCzNwSB.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/xCzNwSB.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/xCzNwSB.png 2x" /> <p dir="auto">블록 체인 기술에서는 하나의 정적 블록이 여러 개의 트랜잭션을 담고 있고, 그런 정적 블록을 시간 순으로 정렬된 시퀀스로 구성합니다. IOTA는 블록 체인과 다르게 시간 순서로 된 정적 블록의 시퀀스를 만들지 않습니다. 대신에 하나의 트랜잭션이 다른 트랜잭션에 병렬적으로 추가될 수 있습니다. 이제부터 그림과 설명을 통해 IOTA에서 트랜잭션을 어떻게 추가하고 검증하며 합의를 이루는지 알아보겠습니다. <p dir="auto">위의 그림에는 탱글(Tangle) 네트워크가 나와있습니다. 앞으로 나올 여러 시나리오는 이 그림을 바탕으로 진행됩니다. <p dir="auto">초록색 네모는 네트워크에서 높은 신뢰도를 가진 확정된 트랜잭션을 나타내고, 파란색 네모는 부분적으로 확정된, 즉 낮은 신뢰도로 확정된 트랜잭션을 나타냅니다. 회색 네모는 아직 아무 검증도 받지 못한 트랜잭션을 나타냅니다. 노란색 네모는 방금 새로 생긴 트랜잭션을 나타냅니다. 나중에 나올 빨간색 네모는 충돌이 있거나 유효하지 않은 트랜잭션을 나타냅니다. 회색 네모나 노란색 네모처럼 아직 검증 받지 않은 트랜잭션을 팁이라고 합니다. <p dir="auto">위의 그림에서 <code>α는 비정상적인 트랜잭션 입니다. <code>α는 <code>h와 <code>l를 참조하고 있는데, <code>α는 자기가 추가될 때 팁이었던 <code>l과 함께, 이미 <code>l에 의해 참조되고 있으므로 명백하게 팁이 아닌 상태인 <code>h를 참조하기 때문입니다. 비정상적이긴 하지만 문제가 되지는 않으며 현재 시점에서는 네트워크에서 그냥 용인됩니다. <h2>새 트랜잭션 추가 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/VEhr0LW.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/VEhr0LW.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/VEhr0LW.png 2x" /> <p dir="auto">탱글 사용자가 새 트랜잭션 <code>1을 추가하려면 <code>w과 <code>x 두 개의 팁을 무작위로 선택하고, 그 <code>w과 <code>x를 검증해야 합니다. 검증이란 팁의 시그너처, 작업 증명(스팸 방지를 위한 낮은 난이도의 작업 증명)을 검사하고, 팁이 직간접적으로 참조하는 과거의 트랜잭션과 충돌이 없는지 확인하는 것을 말합니다. 선택한 팁에 문제가 없다면 사용자는 그 두 개의 팁 <code>w와 <code>x를 참조하는 새 트랜잭션 <code>1을 탱글에 추가합니다. <p dir="auto">선택된 두 개의 팁 <code>w와 <code>x에 의해 직간접적으로 참조되지 않는 트랜잭션(회색 경계 밖에 있는 <code>l, <code>o, <code>r, <code>t, <code>v, <code>y, <code>z)은 <code>1이 탱글에 추가되는 과정에서는 검증되지 않습니다. 이 트랜잭션들은 나중에 다른 트랜잭션이 추가될 때 검증됩니다. <h2>다른 트랜잭션의 추가 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/y9vIdMj.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/y9vIdMj.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/y9vIdMj.png 2x" /> <p dir="auto"><code>1이 추가됨과 거의 동시(직전이든 직후든 상관없음)에 다른 사용자가 새로운 트랜잭션 <code>2를 <code>1과는 다른 위치에 추가하려고 합니다. <code>2는 두 개의 팁 <code>y와 <code>z를 선택해서 앞에서 설명한 것처럼 검증합니다. <code>1에 의해 검증되었던 <code>a, <code>b, <code>c, <code>d, <code>e, <code>f, <code>g, <code>h, <code>i, <code>j, <code>k, <code>m, <code>n은 <code>2에 의해서도 또 한 번 검증되고, <code>l, <code>o, <code>r, <code>t, <code>v, <code>y, <code>z는 <code>2에 의해 검증됩니다. <h2>탱글 상태의 변화 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/Byjez9N.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/Byjez9N.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/Byjez9N.png 2x" /> <p dir="auto"><code>1과 <code>2에 의한 검증 경로를 겹쳐보면 위의 그림과 같습니다. 어떤 트랜잭션은 <code>1이나 <code>2중 한 쪽에 의해서만 확정되고, 어떤 트랜잭션은 <code>1, <code>2 모두에 의해 확정됩니다. 현재 시점에 존재하는 팁 모두에 의해 검증되고 확정된 트랜잭션들은 '완전 확정'되었다고 합니다. 그래서 <code>n은 새롭게 전체 확정되어 탱글에서 더 깊숙히 들어가고 초록색 네모로 바뀝니다. <code>1 또는 <code>2에 추가되는 자손 트랜잭션들은 <code>n을 계속해서 재검증하게 될 것입니다. <p dir="auto">여기서 알 수 있는 것은? <ul> <li><p dir="auto">어떤 사용자도 모든 트랜잭션을 확인하고 검증할 필요는 없습니다. 모든 사용자는 2개의 트랜잭션과 그의 조상 트랜잭션을 선택하고 검증하면 됩니다. 이를 통해 탱글의 일부분을 검증하게 되겠죠. 다른 사용자들은 다른 팁과 조상 트랜잭션을 선택하고 검증할테고, 이 모두의 총합은 결국 탱글 전체를 검증하게 됩니다. <li><p dir="auto">시간이 지나서 한 트랜잭션이 충분히 많은 검증을 받으면, 이 트랜잭션은 탱글에 새로 추가되는 모든 트랜잭션의 검증 경로에 직간접적으로 포함됩니다. 이런 트랜잭션은 완전히 검증되었다고 볼 수 있으며 새 트랜잭션이 추가될 때마다 계속 검증되고 확정될 것입니다. 그럼 이 트랜잭션은 모든 사용자(또는 기계)로부터 확정되었다고 가정할 수 있으며, 높은 확실성을 가지고 있다고 가정할 수 있습니다. <li><p dir="auto">확정 여부를 검사하려면 송금자로부터 IOTA를 받는 수금자는 자신에게 지불하는 정보를 담고 있는 트랜잭션이 탱글에 존재하는 모든 팁으로부터(또는 좀더 낮은, 예를 들어 80%의 확실성만으로도 괜찮다면 80%의 팁으로부터) 직간접적으로 참조되고 있는지만 검사하면 됩니다. 해당 트랜잭션을 별도로 다시 검증하거나 비슷한 절차를 거칠 필요가 없습니다. 주의: 수천 개의 팁이 존재할 수 있으므로 모든 팁의 부모를 검사하는 대신에 무작위 샘플을 선정해서 통계적인 평가를 하는 것도 가능합니다. <p dir="auto">팁의 갯수가 너무 작으므로 <code>n은 아직 확정되었다고 볼 수는 없습니다. 더 많은 팁을 포함하고 있는 다음 그림에서 설명을 이어갑니다. <h2>확정도 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/6Ct1D5Y.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/6Ct1D5Y.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/6Ct1D5Y.png 2x" /> <p dir="auto">이번에는 팁의 갯수가 더 많은 확장된 그림으로 살펴봅시다. 새 팁은 각자의 검증 경로가 있고, 그림에서 옅은색 영역으로 표시되어 있습니다. 영역이 겹칠 수록 색이 짙어지는 것을 유심히 보면 어떤 트랜잭션이 얼마나 많은 팁에 의해 검증되는지와 그에 따른 확정도가 어느 정도인지 알 수 있습니다. <p dir="auto">IOTA를 받는 수금자는 허용 확정도를 스스로 정할 수 있습니다. 트랜잭션 속도가 거래 금액보다 더 중요하다면(즉, 액수가 매우 작은 마이크로 트랜잭션 또는 0원 짜리 트랜잭션), 또는 송금자가 믿을 만한 친구라면 75%의 확정도면 충분할 겁니다. 허용 확정도가 75%라면, 다시 말해 4개 팁 중에서 3개의 팁으로부터 검증을 받으면 되는 수준이라면, 그림에 표시된 4개의 팁 중 <code>2, <code>3, <code>4 세 개의 팁으로부터 검증 받은 <code>l, <code>o, <code>t는 확정되었다고 볼 수 있습니다. <h2>전파 지연 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/Pyuvqxc.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/Pyuvqxc.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/Pyuvqxc.png 2x" /> <p dir="auto">작업증명이 오래 걸릴 수도 있고, 트랜잭션의 전파가 지연될 수 있으므로 이론적으로는 <code>5 같은 느린 트랜잭션이 뒤늦게 탱글에 추가될 수 있습니다. <code>5가 추가되기 전에는 <code>n이 모든 팁으로부터 검증을 받은 상태였지만, <code>5의 검증 경로에는 <code>n이 포함되지 않으므로 <code>5가 추가되면 <code>n은 더이상 모든 팁으로부터 검증 받은 트랜잭션이 아닌 상태로 바뀝니다. 하지만 확정도는 80%로 여전히 매우 높습니다(그림에서는 5개의 팁만 있지만 실제로는 수천 개의 팁이 있을 것입니다). <p dir="auto"><code>5가 추가된다고 해서 <code>n의 상태가 확정에서 미확정으로 바뀌지는 않습니다. 단지 수학적으로 정확한 확정도 값이 변할 뿐입니다(예를 들어 99개의 팁 모두로부터 검증을 받은 상태였다가 새로 추가된 1개의 팁으로부터 검증을 받지 못하게 되었다면 확정도는 100%에서 99%로 변합니다). <code>5가 추가된 후에 새로 추가된 팁이 <code>1과 <code>5를 참조한다면 <code>n의 확정도는 다시 100%로 변합니다. 더 많은 트랜잭션이 탱글에 추가된다면 미미하나마 이런 확정도 변동이 생길 가능성도 작아집니다. <p dir="auto">어쨌든 100%의 확정도는 획득하는 것은 어려운 일이라는 점을 알아둘 필요가 있습니다. 왜냐하면 비정상적인 트랜잭션을 참조하거나 정해진 프로토콜을 따르지 않는 악의적인 팁이 존재할 수 있기 때문입니다. <h2>이중 지불 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/ikL18Ic.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/ikL18Ic.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/ikL18Ic.png 2x" /> <p dir="auto">사용자가 두 개의 충돌되는 트랜잭션 <code>w와 <code>y를 탱글의 서로 다른 영역에서 발생시켰다고 가정해봅시다. 그 이후에 추가되는 트랜잭션은 팁 선정이나 전파 지연 때문에, 충돌되는 트랜잭션인 <code>w와 <code>y 중 하나의 트랜잭션만 검증 경로에 포함할 가능성이 있습니다. <p dir="auto">예를 들어 <code>1을 탱글에 추가하는 사용자와 <code>2를 탱글에 추가하는 사용자는 <code>w와 <code>y가 충돌된다는 사실을 알 수 없으며, 결과적으로 <code>w와 <code>y를 충돌 없는 유효한 트랜잭션으로 판별하게 됩니다. <p dir="auto">하지만 그 충돌은 머지 않아 발견됩니다. 예를 들어 <code>1과 <code>2를 참조하는 <code>5가 추가되면 <code>5의 검증 경로에는 <code>w와 <code>y가 모두 포함되므로 <code>5는 충돌을 발견할 수 있습니다. 그래서 <code>5는 <code>1과 <code>2를 선택하지 않고 충돌이 없는 다른 두 개의 팁을 다시 선택할 겁니다. 그래야 <code>5 자신이 나중에 추가되는 트랜잭션에 의해 유효한 트랜잭션으로서 검증 받을 수 있기 때문입니다. <p dir="auto">팁 선정 알고리듬과 탱글 프로세스에 따르면 충돌이 명백하게 발견되기 전에 <code>w와 <code>y 중 하나만 검증 경로에 포함한 많은 사용자는 <code>w와 <code>y의 충돌을 발견할 수 없으므로, <code>w와 <code>y를 유효한 트랜잭션으로 인정할 가능성이 있습니다. <p dir="auto">하지만 결국에는 사용자들이 새로운 트랜잭션을 <code>w를 검증 경로에 포함하는 팁과 <code>y를 검증 경로에 포함하는 팁 중 어느 쪽에 더 많이 추가했느냐에 따라 <code>w와 <code>y 둘 중 하나만 확정되고 나머지 하나는 버려집니다. <p dir="auto">버려진 쪽에 추가된 트랜잭션들은 충돌이 있었는지 몰랐지만 억울하게도 함께 버려집니다. 하지만 충돌을 모른채 버려진 트랜잭션들이 탱글에서 아예 사라지는 것은 아니고 다른 사용자(IOTA를 받는 수금자일 가능성이 높습니다)에 의해 선택되서 탱글에 다시 추가되고 검증 받을 수 있는 기회를 얻게 됩니다. <p dir="auto">검증을 받으려면 작업 증명이 다시 실행되겠지만 송금자로부터 거래 승인 정보를 다시 받아와야 할 필요는 없습니다. <h2>이중 지불 문제 해결 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/PvYUUpM.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/PvYUUpM.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/PvYUUpM.png 2x" /> <p dir="auto">앞의 이중 지불 그림에서 사용자는 <code>5를 <code>1과 <code>2에 추가하려고 했지만, <code>w와 <code>y가 충돌된다는 걸 발견하고는 팁을 다시 선택해서 <code>1과 <code>4를 선택했고, <code>1과 <code>4에서는 충돌이 발견되지 않았으므로 <code>5는 <code>1과 <code>4에 추가 되었습니다. 다른 사용자는(반드시 다른 사용자일 필요는 없습니다) <code>7을 <code>2와 <code>3에 추가 했습니다. <p dir="auto">이렇게 되면 <code>w를 포함하는 경로와 <code>y를 포함하는 두 가지 경로로 일종의 분기가 발생하지만, 앞의 이중 지불 단원에서 설명한대로 둘 중 하나는 버려지고 하나만 살아남게 됩니다. 트랜잭션의 누적 가중치를 감안한 무작위 팁 선택 로직에 의해, 분기된 두 경로 중 한 쪽 경로에 더 많은 자손 트랜잭션이 추가될 것 입니다. <p dir="auto">그리고 시간이 지나면 누적 가중치를 감안한 팁 선택 알고리듬에 의해 한 쪽 경로에는 정상적인 방법으로 트랜잭션을 추가하는 것이 불가능해집니다. 앞의 그림에서 <code>5, <code>6, <code>8 다음에는 새로운 트랜잭션이 계속 추가될 수 있지만, <code>7 다음에는 트랜잭션을 추가할 수 없게 됩니다. 그래서 <code>y, <code>2, <code>3, <code>7은 더 이상 검증을 받지 못하게 되고 완전 확정 상태가 될 수 없습니다. <p dir="auto">이중 지불 단원에서 설명한 것처럼 버려지는 경로에 있던 <code>y, <code>2, <code>3, <code>7은 일단 탱글에서 떨어져나간 후에 다른 새로운 트랜잭션들에 의해 검증되면 다시 탱글에 추가될 수 있습니다. <code>y, <code>2, <code>3, <code>7 각각이 유효한 트랜잭션이라면 다른 정상적인 트랜잭션과 마찬가지로 결국에는 확정될 수 있습니다. 그래서 <code>2, <code>3, <code>7은 확정될 수 있지만 충돌 내용이 포함된 <code>y는 끝내 확정될 수 없습니다. <h2>오프라인 탱글 <p dir="auto"><img src="https://images.hive.blog/768x0/https://i.imgur.com/60kh0yc.png" alt="Imgur" srcset="https://images.hive.blog/768x0/https://i.imgur.com/60kh0yc.png 1x, https://images.hive.blog/1536x0/https://i.imgur.com/60kh0yc.png 2x" /> <p dir="auto">탱글 사용자는 탱글 네트워크에 연결되어 있지 않은 오프라인 네트워크에서도 트랜잭션을 계속 붙여나갈 수 있습니다. 그러기 위해서는 트랜잭션이 프로토콜로 정해진 규약에 따라 생성되고 연결되어야 합니다. <p dir="auto">오프라인 네트워크는 외부 인터넷 연결이 끊어져서 메인 탱글 네트워크에 연결할 수는 없지만, 인트라넷처럼 내부의 연결은 가능한 상태의 네트워크를 말합니다. <p dir="auto">위의 예제 그림에서 <code>1과 <code>2는 처음으로 온라인 탱글 네트워크와 연결이 끊어져서 오프라인 상태가 된 트랜잭션 입니다. 그 둘은 온라인 탱글의 가장 끝에 있던 팁인 <code>r과 <code>t에 연결되어 있습니다. <p dir="auto">노란색 영역으로 표시된 오프라인 네트워크에서 <code>1과 <code>2 이후에 발생하는 트랜잭션은 온라인 네트워크일 때와 마찬가지 방식으로 <code>1과 <code>2를 조상으로 해서 계속해서 추가됩니다. <p dir="auto">다시 인터넷과 연결되어 오프라인 네트워크의 트랜잭션들을 다시 메인 탱글 네트워크에 연결할 수 있게 되면, 메인 탱글 네트워크와 방금 다시 온라인 네트워크가 된 노란색 영역 모두를 볼 수 있는 <code>8이 메인 탱글 네트워크에 있는 <code>y와 오프라인 네트워크에 있던 <code>7을 선택해서 검증하면서 오프라인 네트워크와 메인 탱글 네트워크를 병합합니다. 나중에 <code>8에 트랜잭션이 추가되면 오프라인 네트워크에 있던 <code>1, <code>2, <code>3, <code>4, <code>5, <code>6, <code>7이 검증 경로에 포함되어 함께 검증됩니다. <p dir="auto">오프라인 네트워크에 있던 트랜잭션이 완전 확정 상태가 되려면, 메인 탱글 네트워크에 있는 트랜잭션과 마찬가지로 충돌이 없어야 합니다. 만약 <code>1~<code>7 중에서 하나라도 메인 탱글 네트워크에 있는 트랜잭션과 충돌이 있다면, <code>1~<code>8 모두 확정되지 못합니다. 이중 지불 단원에서 설명한 것처럼 충돌이 메인 탱글에 있는 모든(또는 대다수의) 팁에 의해 발견되려면 어느 정도 후속 트랜잭션이 탱글 네트워크에 추가되어야 합니다.