부분적으로 서명 된 거래의 통합 이론

이것은 ElectrumSV가 서명되지 않은 (또는 불완전한) 트랜잭션 (대부분 내 자신의 기록)에 대한 상태를 (자연스럽게) 추적하고 유지할 수있는 방법에 대한 현재의 생각 프로세스에 대한 자세한 기록 일뿐입니다. 이러한 아이디어는 ElectrumSV 개발자 (즉, Roger Taylor)와의 토론을 기반으로합니다 (그러나 결코 보증하지 않음).

현재 데이터베이스는 StateSigned 작업 n 만 기록합니다 (그리고 그 이후의 모든 상태-즉, StateDispatched, StateCleared, StateSettled가 최종 순서로 표시됨)… 핵심은 이러한 모든 상태 ( 이 txid는 다른 테이블 (예 : TransactionOutputs 및 TransactionDeltas 테이블)에서 외래 키로 사용됩니다.

그러나 부분적으로 서명 된 트랜잭션에는 txid가 없습니다 . 그러나 우리는 여전히이 상태를 추적해야합니다. 그러나 이러한 트랜잭션을 캐시와 RDMS에 어떻게 저장합니까? 이것이 해결해야 할 중요한 문제인 이유는 무엇입니까?

이 문제를 해결해야하는 이유는 무엇인가요?

1. BIP270 결제 요청 (및 페이 메일 p2p 교환 / 신원 프로토콜 사용 사례)은 서명되지 않았거나 부분적으로 서명 된 (불완전한) 트랜잭션을 유지해야합니다.

2. 다중 스레드 트랜잭션 생성을 위해서는 두 스레드가 동일한 utxo에 액세스하거나 주어진 출력에 대해 동일한 새 키 를 선택하지 않도록해야합니다 (키 재사용을 방지하려는 경우). 그러나 utxo 또는 키를 ‘사용 / 할당 됨’으로 표시하면 실제로 사용한 데이터에 대한 지속성 데이터가 필요합니다! ( i.e. 거래가 어디입니까!? — txid가 없습니다… 전혀 발생하지 않은 것 같습니다…)

3. 트랜잭션 서명 단계에서 우리는 script_type을 설정할 수 있도록 각 출력과 연관된 keyinstance_id를 알아야합니다 (따라서 ‘더 이상 신선하지 않음’으로 표시합니다. 이렇게하면 다른 스레드가이를 사용하지 못합니다. 그러나 서명되지 않은 트랜잭션이 어떻게 말했는지 기억하십시오. txid가 없으세요? 예… 어떻게 서명을 수행하는 함수가이 서명되지 않은 트랜잭션의 출력에 대한 keyinstance_ids를 어떻게 조회합니까? 레코드가없는 경우 (특히 BIP270의 경우 상태는 서명되지 않은 tx 단계와 서명 사이에 재부팅에서 살아남 아야합니다 . 현재는 할 수 없습니다… 그래서 그렇지 않습니다. 모든 키 인스턴스에 대한 기본 scriptpubkey를 힘들게 생성 할 수 있다고 생각할 수 있습니다. ) 매칭 게임을하고 …하지만 다른 무한한 종류의 출력 스크립트는 어떻습니까?! 수밀 솔루션이 아니며 성능이 끔찍합니다. 대신 실제로 서명되지 않은 트랜잭션을 유지하고이 문제를 단번에 해결해야합니다.

4. 시퀀스 번호가 증가하고 nLocktime이 미래 날짜 (최종이되어 채굴 될 때)로 설정된 지불은 나중에 (나중에 주어진 출력에 대한 주요 인스턴스를 쉽게 조회 할 수있는 방법을 필요로합니다. 위의 3 번 참조).

ESV는 현재 키 기록을 추적하고 키를 ‘사용됨’으로 표시하기 위해 전적으로 ElectrumX에 의존합니다 (따라서 게시-구독 알림을 통해 StateCleared에서 상태를 추적 할 수 있음). 따라서 집으로 돌아 가기 위해 서명되지 않은 상태를 추적하지 않는 효과에 대한 흐름은 실제로 StateSigned 및 StateDispatched 상태를 완전히 추적 할 수없는 상황으로 이어집니다! (로컬로 생성 되더라도 예)

캐시와 RDMS에 이러한 트랜잭션을 어떻게 저장하나요?

이는 모든 서명되지 않은 상태와 서명 된 상태를 항상 추적하고 향후 요구 사항 (예 : p2p 지불 채널?)을위한 모든 기반을 포괄하는 방식으로 통합 모델에서 처음으로 균열을 일으켰습니다.

새 데이터베이스 테이블

StagedTransactions 표

‘스테이지’라는 용어는 git 용어를 빌리기 위해 ‘커밋 된’것과는 대조적입니다 (그리고 비트 코인 네트워크에 ‘커밋 된’것과 관련하여 사용되며 txid가 필요함).

StagedOutputs 테이블

StagedInputs 테이블

필요하지 않음 — 트랜잭션 입력은 정의에 따라 txid 및 색인을 참조해야하므로 서명 된 트랜잭션 출력을 참조합니다. 따라서 — keyinstance_id에 필요한 기존 TransactionOutputs 테이블을 참조하십시오.

참고 : 이러한 서명되지 않은 트랜잭션 입력 / utxos는 TransactionOutputs 테이블에서 즉시 지출 된 것으로 표시 될 수 있습니다 (이제 “트랜잭션이 어디에 있습니까?!”라는 질문에 대한 답이 있기 때문입니다)

서명되지 않은 트랜잭션이 삭제되면 출력이 다시 ‘사용되지 않음’으로 표시 될 수 있습니다.

새로 캐시 된 데이터 구조

staged_txs = {uuid : (electrumsv.transaction.Transaction, 플래그)}

# 플래그에는 다음이 포함됩니다.
-EPHEMERAL은 전송중인 서명되지 않은 트랜잭션 일 뿐이며 db (성능 향상을 위해)에 지속될 필요가 없음을 나타냅니다. utxos / fresh_keys도 해당 캐시에서 가져와 유지되지 않습니다. 갑작스런 재부팅 (사용 기록이 없기 때문에)의 경우 분실됩니다. 상관 없습니다.
IS_PAYMENT_REQUEST는 이것이 BIP270 결제 요청이며 생성되었음을 나타냅니다
의도 있음 이 db에 유지됩니다.

staged_utxo_keys = {(uuid, index) : keyinstance_id}

keyinstance_id의 간편한 조회를 제공합니다 (서명 된 tx 출력을 반복하고 keyinstance script_type 을 설정합니다 (암시 적으로 ‘사용됨’으로 표시합니다. 한 번 이상). 임시 유형 tx 인 경우 Account._keyinstances 는 캐시와 DB 모두에 대한 write-through를 수행하지 않는 경우 캐시합니다.

참고 : 다음과 같은 중요한 차이점이 있습니다.
1) 적어도 한 번 ‘사용 된’키 (예 : script_type이 설정되고 다른 tx 생성 스레드에 대해 더 이상 ‘새 키’의 구성원이 아님) 받는 사람 :
2) 잔액이 0에 도달하고 이후 구독 취소되기 때문에 ‘사용’/ ‘보관’된 키… 일명 “보관 됨”— KeyInstanceFlag.IS_ACTIVE 또는 USER_SET_ACTIVE 그리고 모든 utxos를 받고 사용했음을 의미하며 +이 이벤트가 블록 체인에서 확인되었음을 의미합니다.

SyncState 변경

현재 wallet.SyncState 는 StateCleared 및 StateSettled 트랜잭션에 대한 key_history 만 추적합니다. 그러나 추적되고 서명되지 않은 tx 상태가 도입됨에 따라 로컬 tx 서명 시점부터 기록 추적을 시작할 수 있습니다.

이것은 (지금까지) StateCleared txid를 포함하는 key_history에만 의존했던 코드베이스의 일부에 대해 매우 사소한 의미 일뿐입니다.

다른 트랜잭션 상태를 추적하는 경우 기록에서 txid에 대해 TxFlag (StateSigned / StateDispatched…)를 확인하기위한 추가 단계가 필요합니다.

다른 한편으로 utxos를 spent 로 설정하면 가능한 가장 빠른 단계 (서명되지 않은 트랜잭션을 생성 할 때)에서이를 수행 할 수 있습니다. 따라서 utxo는 스레드로부터 안전한 사전 서명을 사용하게됩니다.

다중 스레드 트랜잭션 생성

이것은 보너스 작업이지만 이론적으로 다음과 같은 ‘버킷’을 할당 할 수 있습니다.

1. 공유 스레드 잠금 풀의 새 키와 서명을위한 개인 키

2. Utxos

3. 거래 결과

이 최소한의 필수 데이터를 파이프하여 실행중인 CPU 프로세스를 분리하고 서명되지 않은 트랜잭션을 생성하도록 할 수 있습니다. 독립적으로 서명하십시오. 그런 다음 필요하지 않은 utxos 및 새 키를 사용하여 서명 된 트랜잭션을 반환합니다. 새 키 및 utxos의 공유 풀로 다시 릴리스됩니다.

아이디어는 많은 수의 utxos와 새로운 키를 대기 상태에 두어 10 개의 프로세스가 한 번에 각 트랜잭션에 대해 10 개의 새로운 키와 10 개의 utxos를 가질 수 있도록하는 것입니다.

참고 : 고갈되었을 때 새 키 풀을 보충하면 매번 데이터베이스에 쓰기가 필요하기 때문에 성능 병목 현상이 발생합니다. 따라서 처리량이 많은 작업의 경우 대량의 키 생성이 가능하도록 대규모 새 키 풀이 선호됩니다. 풀에 새로운 키가 충분하지 않아 수요를 충족 할 수 없을 때만 수행됩니다 (예 : 10 개 미만) (그리고 단일 데이터베이스 트랜잭션은 매번 500 개의 새로운 키를 생성 할 수 있음).

Identity Pubkey 연결을위한 메타 데이터

Roger Taylor (https://medium.com/@roger.taylor)는 다중 서명 입력 서명을 ID에 연결하는 데 메타 데이터가 필요하다는 점을 지적했습니다 (예를 들어 UI에서 해당 아바타의 후속 표시).

따라서 위의 부록으로 XTxInput 객체에 다음을 포함하는 튜플 목록 인 sig_link 속성도 포함 할 것을 제안합니다.

· sig_index — 즉, 0은 첫 번째 서명을 의미합니다.

· 연락처 테이블을 참조하는 identity_pubkey_id — (다음 참조) :

(최대) 많은 서명. 해당하는 sig_link 항목이없는 서명은 실제로 누가 서명했는지 알 수 없다는 의미입니다. 때로는 괜찮은가요? 아니면 아닐 수도 있습니다. 모르겠어요.

연락처 표

결론

나는 현재 단계에서 가능한 방법에 대한 피드백을 얻기 위해 아이디어를 던지고 있습니다. 이 모델에서 거래를 방해하거나 결함을 발견하면 알려주세요.

부분적으로 서명 된 트랜잭션의 구성 요소를 여러 정규화 된 관계형 데이터베이스 테이블로 분할하는 것이 더 낫습니다 (직렬화 / 역 직렬화를위한 하나의 이진 블롭보다는)…하지만 제 생각에 이러한 비트 코인 트랜잭션은 가까운 장래에 (특히 지갑에 필요한 다른 메타 데이터에 레이어 할 때). 그래서 지금은 지속성이 필요한 부분적으로 서명 된 트랜잭션에만 데이터베이스를 사용하고 지속성이 필요하지 않은 경우 캐시 된 데이터 구조를 사용하도록 제안하고 있습니다 (따라서 작업을 수행 할 때마다 3 개 또는 4 개의 다른 테이블을 업데이트 할 필요가 없습니다. 거래!).