UTXO 모델과 prune

• transfer는 account-balance 모델
• pay, fee는 UTXO(Unspent Transaction Output) 모델 -> pay와 fee는 같은 계좌를 바라봄
  • 만약 pay를 account balance 모델로 받으면, 동시에 pay가 일어날 때 한명만 성공하고 나머지가 다 실패할 수 있다. 그래서 그렇게 안하고 UTXO 모델을 사용한다.
  • UTXO 모델을 사용하여 pay건들을 모아서 한번에 처리한다.(prune)
  • unspent로 pay, fee 들을 모아서 정책에 따라 각각의 처리 계좌로 보냄
• 비트코인은 tps가 약 1000개, 패브릭은 tps가 약 3500개
• 비트코인에서는 트랜잭션이 되게 간단한 트랜잭션이다(예: 숫자 1을 저장)
• 그에 비해 payprotocol에서 결제에 관련되어 일어나는 트랜잭션은 복잡하여, 트랜잭션 1개 처리하는데 걸리는 시간이 오래걸림
• UTXO 모델도 들어가서 시간이 오래 걸림

• 그래서 tps 자체가 굉장히 적은 수치

• CouchDB에서 한 번에 select, update 할 수 있는 개수가 정해져있음 -> default로 1000개 정도

• 그래서 UTXO 모델로 prune 할 때 한번에 merge 할 수 있는 양은 1000개보다 적게 잡아야 한다

• 그래서 pay, fee를 보면 약 900개 정도만 select 해서 시작id와 끝id를 잡아서 시작부터 끝까지 sum을 해서 balance에 합쳐주고, 그 다음에 어디까지 prune했는지 id만 저장해서 관리(마지막으로 끝냈던 id만 저장), 기록을 실제로 지우지는 않는다(기록은 계속 남는다)

• 이렇게 해서 select는 개수만큼 일어나지만, 900개를 기준으로 update는 pay 1번이랑 fee 1번이랑 해서 2번으로 끝난다.

• UTXO 모델을 이용하지 않고 account-balance 모델을 이용했다면 pay 900건에 대해서 select 900번 + update 1800번 = 2700번이 일어날 수 있었으나, UTXO 모델을 사용함으로써 pay 900건에 대해서 select 900번 + update 2번 = 902번으로 확 줄었다.

• select의 양은 똑같지만, update를 2번으로 줄임으로써 퍼포먼스는 더 나아졌음

• txid를 time을 가지고 integer로 바꿔서 만듬, fee를 txid 순으로 정렬하면 시간순으로 정렬됨 -> 이 time은 다날 app server(sdk를 사용해서 tx를 날리는 서버)의 시간인데, 이 app server가 1개가 아니라, 여러 개일 경우 각 server의 시간이 다를 수 있음 -> fee prune이 일어날 때 900개씩 처리한다고 하면, 900개 처리하고 있을 당시 새로운 fee가 들어왔는데 이 fee가 서버시간의 차이로 처리하고 있던 900개의 fee들보다 시간이 빠른 fee가 들어와버리면, 이 fee는 이 다음 fee prune을 처리할 때 제외 대상이 되어 버린다.(시간순으로 정렬하여 처리하므로) -> fee prune 시 건들지 않기 때문에 영원히 소실되어버리는 fee가 된다.

• prune은 pay prune과 fee prune 2가지가 있다.
• prune은 start time과 end time을 줄 수 있다. 이 때 prune의 start time을 지금보다 10분이 지난 후의 시간을 넣어야 한다.