This is translation of JUMBLR whitepaper into korean.
간단하게 구글번역기의 도움을 약간 받아서 Jumblr 백서(whitepaper)를 번역해보았습니다.
Jumblr는 Bitcoin을 비롯한 거의 모든 가상화폐를 익명화시킬 수 있는 중계 플랫폼입니다.
Supernet.org 에서 개발되고 있으며 현재 KMD기반으로 Agama 지갑에 test version 으로 구현,공개되어 있습니다.
좀 더 자세한 JUMBLR에 대한 설명은 공부하면서 차차 포스팅해보도록 하겠습니다.
※ 본 문서는 아직 draft 이며 정식 등록된 것이 아님을 미리 언급해둡니다. 차후 내용이 원문에 추가되거나 정식 공개가 되면 추가 포스팅을 통해 공유해드리도록 하겠습니다.
원본문서(draft) : 구글문서열기
번역문서 : 구글문서열기
JUMBLR
Komodo based fully decentralized anonymizer
utilizing native DEX
JUMBLR
기존 DEX를 활용한 Komodo 기반의 완전히 분산화된 익명화 서비스
Abstract:
개요:
The problems with bitcoin not being anonymous are well known, as are the risks of using a centralized mixing service where you give up control of your coins for the duration. Other decentralized coin mixing methods, like coin shuffle, require coordinating with other parties for each mix and the possibility of a mix being disrupted, or even worse, privacy leaked.
비트코인이 익명성을 보장하지 못한다는 문제점은 잘 알려져있으며, 중앙화된 복합적인 서비스를 이용함에 있어서 감수해야할 위험요소이기도 합니다. 코인 셔플과 같은 다른 분산 형 동전 혼합 방법은 각 믹스에 대해 다른 당사자와 협조해야하며 믹스가 중단되거나 더 나쁜 경우 개인 정보 유출 가능성도 야기시킵니다.
JUMBLR solves all these issues with a two layer approach. At the core is the Komodo JUMBLR process that is built into iguana. It works with KMD and converts ordinary KMD into anonymized KMD. Of course care must be taken after it is anonymized to not lose it, but the ability to create the anonymized KMD in a fully decentralized way with no direct group of other parties is a vast improvement.
JUMBLR은이 두 가지 문제를 두 가지 방식으로 해결합니다. 핵심은 이구아나에 내장 된 Komodo JUMBLR 프로세스입니다. 그것은 KMD와 함께 작동하고 일반 KMD를 익명의 KMD로 변환합니다. 물론 그것을 잃어 버리지 않도록 익명화 된 후에주의를 기울여야 만합니다. 그러나 익명으로 처리 된 KMD를 다른 당사자의 직접적인 그룹이없는 완전히 분산 된 방식으로 만드는 능력은 엄청나게 향상되었습니다.
Building on top of the JUMBLR core is the native DEX using cross chain atomic swaps to convert BTC (or any other bitcoin protocol coin) into KMD, doing the JUMBLR and then using DEX again into an anonymized BTC address. In a sense, JUMBLR is a client of the iguana DEX service. Since the native DEX has been described already, it will only be referred to here as a mechanism that is able to convert BTC <-> KMD, thus reducing the anonymization problem to converting transparent KMD into anonymized KMD.
JUMBLR 코어 위에 구축하는 것은 교차 체인 아토믹 스왑을 사용하여 BTC (또는 다른 비트 코인 프로토콜 동전)를 KMD로 변환하고 JUMBLR을 수행 한 다음 DEX를 익명의 BTC 주소로 다시 사용합니다. 어떤면에서 JUMBLR은 이구아나 DEX 서비스의 클라이언트입니다. 네이티브 DEX는 이미 설명되었으므로 여기서는 BTC KMD를 변환 할 수있는 메커니즘으로 만 언급되므로 익명 처리 문제가 줄어들어 공개된 KMD가 익명화 된 KMD로 변환됩니다.
※ cross chain atomic swap : 서로 다른 체인에 속한 거래당사자가 직접 통신하여 거래하는 것.
※ native DEX : 여기(클릭) 있는 코모도 백서 참조
At first, it might seem that simply using the innate zcash protected Ztransactions will be sufficient. However, there are some pitfalls to just naively using the Ztransactions and to benefit from most of the protection a few attacks need to be prevented.
처음에는 zcash로 보호 된 Ztransactions만으로 충분할 것처럼 보입니다. 그러나 Ztransactions를 있는그대로 사용하고 몇 가지 공격을 방지해야하는 대부분의 보호 기능을 활용하려면 몇 가지 함정이 있습니다.
A) Timing attack
B) Knapsack attack
A) Timing attack is especially an issue when there are not many ongoing JUMBLR processes. At the degenerate case of only a single JUMBLR process going on, there is actually no anonymization provided at all! After all, if you know who started the JUMBLR process (we do due to transparent address) and if there is only one active participant, it doesn’t take any difficult analysis to determine whose coins come out of the JUMBLR process.
A) 진행중인 JUMBLR 프로세스가 많지 않은 경우 타이밍 공격이 특히 중요합니다. 하나의 JUMBLR 프로세스만 진행되는 좋지않은 상황에서는 실제로 익명화가 전혀 제공되지 않습니다! 결국 JUMBLR 프로세스를 시작한 사람이 누구인지 (공개된 주소로 부터 수행하게 됨) 알고 있고 이를 적극적으로 활용하는 이가 한 명뿐이라면 누가 JUMBLR 프로세스를 이용하여 익명화한 동전인지 판단하기 어렵지 않습니다.
B) Knapsack attack is somewhat similar to timing attack, but as applied to amounts. If there is only one address that JUMBLR’ed 777 KMD and 777 KMD appears at the output of the JUMBLR process, then again it is not hard to correlate.
B) Knapsack 공격은 타이밍 공격과 다소 유사하지만 수량에 영향을 받습니다. JUMBLR를 거친 777 KMD를 JUMBLR화 한 주소가 하나 밖에 없고, JUMBLR 프로세스를 거친 후 777 KMD를 가지고 있는 주소가 하나 뿐이라면, 다시 연관성을 찾아내기 어렵지 않을 것입니다.
So, while the zcash zksnark proofs shield the value, it is still advantageous to limit the denominations that are allowed for the JUMBLR. To achieve this, three orders of magnitude are allowed, 100 KMD, 1000 KMD and 10000 KMD lots. So all user’s JUMBLR funds end up in one of the three denominations. Still it allows some correlations, but in the presence of a large number of JUMBLR processes, it degrades to noise level correlations, i.e. random guessing.
따라서, zcash가 보증하는 동안 값을 보호 할 수는 있지만 JUMBLR에 허용되는 금액을 제한하는 것이 여전히 유리합니다. 이를 달성하려면 100 KMD, 1000 KMD 및 10000 KMD 묶음으로 세 가지 등급이 허용됩니다. 따라서 모든 사용자의 JUMBLR 자금은 세 가지 금액단위 중 하나에서 완료됩니다. 여전히 연관성을 남겨 두긴 하지만 JUMBLR 프로세스의 수가 많아질수록 노이즈 레벨 연관성, 즉 랜덤 추측수준으로 저하됩니다.
(쉬운설명) B의 공격처럼 특정 금액에서 익명성이 들킬 수 있으니, 100/1000/10000 단위로만 변환하도록 하겠음. 이것도 역추적하면 누구의 것인지 추적할 여지는 있으나 모수가 많아질 수록 추측은 랜덤수준으로 무의미해짐.
If the user can keep KMD in shielded form for a long time, then the anon set grows ever larger. However it is envisioned that a lot of users will simply want to convert the BTC as quickly as possible, so we will concentrate on the JUMBLR operation for such cases keeping in mind that significantly greater privacy is achieved by delaying the conversion out of the shielded (protected) mode KMD.
사용자가 KMD를 차폐 된 형태로 오랫동안 유지할 수 있다면, 익명 세트는 훨씬 더 커질 수 있습니다. 그러나 많은 사용자들이 BTC를 가능한 한 빨리 변환하기를 원할 것이므로 차폐(보호) 모드의 KMD에서 전환을 지연시킴으로써 훨씬 더 큰 프라이버시가 달성된다는 것을 명심하면서 JUMBLR 작업에 집중할 것입니다.
(쉬운설명) JUMBLR변환 작업에 delay가 길수록 익명성이 더욱더 강화됨. 그런데 사람들은 바로바로 변환하고싶어하는 상황임. 암튼 전부 다 고려해서 JUMBLR가 동작하도록 신경쓰겠음
JUMBLR Interface
In order to minimize the complexity of using JUMBLR a very simple interface has been designed. There are two JUMBLR API calls:
JUMBLR 인터페이스
JUMBLR 사용의 복잡성을 최소화하기 위해 매우 간단한 인터페이스로 설계되었습니다. 두 가지 JUMBLR API 호출이 있습니다.
STRING_ARG(jumblr,setpassphrase,passphrase)
ZERO_ARGS(jumblr,status)
Conceptually, iguana is creating an automated payment processor for a single special address, the one that is mapped from the passphrase. Relying on SHA256 to not be reversible, we can generate an arbitrary number of special addresses that are all linked to the main passphrase by just prefixing (or suffixing) special strings. The advantage of making it based on passphrase is that the identical iguana GUI can be used to access the JUMBLR’ed funds as for normal funds.
개념적으로, 이구아나는 암호문에서 매핑 된 하나의 특별한 주소에 대한 자동 지불 프로세서를 만들어 냅니다. 되돌릴 수 없도록 SHA256 방식에 의존하기 때문에, 우리는 특수 문자열 앞에 접두어 (또는 접미사)를 붙이면 주 암호문에 모두 링크되는 임의의 갯수만큼의 특수한 주소를 생성 할 수 있습니다. 암호문를 기반으로하는 이점으로는, 동일한 이구아나 GUI를 사용하여 JUMBLR화된 자금을 일반적인 자금들처럼 사용할 수 있다는 것입니다.
A further simplification is for the JUMBLR passphrase to be derived from the user’s main passphrase by prefixing “jumblr “ to the main passphrase. This removes even the step of specifying a JUMBLR passphrase as it can be done automatically without any ill effect. Unless the user specifically sends funds to the deposit address, JUMBLR stays dormant.
JUMBLR 암호문이 사용자의 메인 암호문에서 "jumblr"접두사를 붙이면 더 간단해집니다. 이렇게하면 아무런 부작용없이 자동으로 수행 할 수 있으므로 JUMBLR 암호 구를 지정하는 단계조차도 필요없게됩니다. 사용자가 입금 주소로 명시적으로 자금을 송금하지 않는 한 JUMBLR은 휴면 상태를 유지합니다.
As soon as JUMBLR detects a deposit has arrived, it can start the t -> z, z -> z, z -> t process, however we need to avoid the Timing attack. So what is done is a very deliberate slowdown to the entire process. Every twentieth minute, the JUMBLR process activates and checks to see if any tasks are pending. Each hour thus has 3 different JUMBLR phases, t -> z, z -> z and z -> t. If it is determined that there is an appropriate transaction to be sent during the special minute, it is processed approx half the time. The reason for this is to make the completion time random as it relates to the amount of funds being JUMBLR’ed and also to avoid having any predictable activity on a node.
JUMBLR이 입금을 감지하면 t -> z, z -> z, z -> t 프로세스를 시작할 수 있지만 Timing 공격을 피할 필요가 있습니다. 따라서 전체 프로세스에 대해 의도적으로 느리게 처리하도록 합니다. 20 분마다 JUMBLR 프로세스가 활성화되어 보류중인 작업이 있는지 확인합니다. 따라서 각 시간에는 3 개의 서로 다른 JUMBLR 단계 t -> z, z -> z 및 z -> t가 있습니다. 특정시간 동안 전송할 적절한 트랜잭션이 있다고 판단되면 약 절반의 시간이 처리됩니다. 그 이유는 JUMBLR화 된 기금 금액과 관련하여 완료 시간을 무작위로 만들고 노드에서 예측 가능한 활동을 피하기 위해서입니다.
(쉬운설명) JUMBLR화되는 과정을 일부러 단계별로 Delay를 주어서 누가 JUMBLR를 통해 익명화를 시도하였는지를 역추적하기 힘들게 섞이도록 해 줌.
The initial step of t -> z determines the lot size by trying the largest 100x size first, then the 10x then the normal. Once it finds a valid lot size it can do, it does a single lot and stops for the phase. The other two phases process whatever total amount it has received and sends it onto the next step.
t -> z의 초기 단계는 가장 큰 100x 크기를 먼저 시도한 다음 10x를, 그 다음 정상으로 시도하여 로트 크기를 결정합니다. 일단 유효한 로트 크기를 찾으면 단 하나의 로트를 수행하고 진행을 멈춥니 다. 다른 두 단계는받은 총 금액을 처리하고 다음 단계로 보냅니다.
Three phases: t -> z, z -> z, z -> t
T -> Z is going from the transparent deposit address to a zaddress. Once in a address the funds are shielded but the fact that it came from a transparent address leaks a bit of information. To fully shield it, a Z -> Z transaction is done and finally to retrieve it to the destination address a final Z -> T transaction completes the cycle.
세 단계 : t -> z, z -> z, z -> t
T -> Z는 공개된 입금 주소에서 zaddress로 이동합니다. 일단 주소가 들어가면 자금이 차폐되지만 공개 주소에서 나온 사실은 약간의 정보를 누출하게 됩니다. 완전하게 보호하기위해, Z -> Z 트랜잭션이 수행되고 마지막으로 대상 주소로 검색해야 최종 Z -> T 트랜잭션으로 송금단계를 완료합니다.
From the relatively simple behavior above, both the timing attack and knapsack attack are defeated, thus fully leveraging the zcash zksnark technology. The more participants in the JUMBLR, the more privacy there is and the cost for having an ongoing JUMBLR is comparable to the APR being earned. In other words for little if any net cost, KMD users can anonymize their funds and provide more privacy for everyone else.
위의 비교적 단순한 동작에서 타이밍 공격과 Knapsack 공격으로부터 안전하므로 zcash zksnark 기술을 완벽하게 활용합수 있습니다. JUMBLR 참여자가 많을수록 개인 정보 보호가 강화되고 진행되는 JUMBLR 비용은 획득 한 APR(이자율)과 비슷합니다. 즉, 순 비용이 거의 없다면 KMD 사용자는 자금을 익명화하고 다른 사람들에게 더 많은 프라이버시를 제공 할 수 있습니다.
BTC layer
In order to provide the practically needed BTC <-> anonymized BTC service, the JUMBLR process monitors the BTC deposit address and when funds arrive, it issues a DEX request to convert to KMD and routes the KMD to the JUMBLR KMD deposit address. Once there the JUMBLR process will automatically process it until it arrives at the destination KMD address. At which point a reverse DEX of KMD to BTC is done from the JUMBLR destination address, thus not leaking any information about the source of the funds.
BTC 레이어
실질적으로 필요한 BTC - 익명 BTC 서비스를 제공하기 위해 JUMBLR 프로세스는 BTC 입금 주소를 모니터링하고 자금이 도착하면 KMD로 변환 할 DEX 요청을 발행하고 KMD를 JUMBLR KMD 보증금 주소로 라우팅합니다. 일단 JUMBLR 프로세스가 목적지 KMD 주소에 도착할 때까지 자동으로 처리합니다. 어느 시점에서 BTC에 대한 KMD의 역방향 DEX가 JUMBLR 대상 주소에서 수행되므로 자금 출처에 대한 정보가 누출되지 않습니다.
Due to market fluctuations it is possible for there to be on the order of 5% price slippage by requiring two open market DEX transactions. While it would be possible to prearrange the swap back, there is no known way to do that without leaking information about the party doing the second half of the swap, so the most private is to rely on the open market DEX LP nodes.
시장 변동 때문에 2 개의 공개 시장 DEX 거래를 요구함으로써 5 %의 가격 차이가 발생할 수 있습니다. 스왑 백을 사전 준비하는 것이 가능할 수도 있지만, 스왑의 후반부에있는 파티에 대한 정보가 누설되지 않으면서 이를 수행 할 수있는 알려진 방법이 없으므로 공개되지 않은 DEX LP 노드에 의존하는 것이 가장 적합합니다.