안녕하세요 @callihappiness입니다. 오랜만에 가상화폐 관련 뉴스 번역으로 찾아왔습니다 DAN이  이 스팀잇을 만들고 지금은 Eos로 이슈인 DAN이 스팀에 올린 글을 번역한 글입니다. eos에 관심이 많은 분들이 많을 거 같아서 올려봅니다

 출처 : https://steemit.com/eos/@dan/eos-developer-s-log-starday-201707-3 입니다!

Today I met with the team to discuss the challenges of making smart contracts both easy to develop and easy to execute in parallel. If you are familiar with the challenges associated with parallel execution then you know the general rule that all data must be owned by a single thread. In terms of blockchains, that means all accounts need to own their data. Owning data means that no other thread of execution may read or write the data except by asynchronous message passing.

오늘 저는 스마트 계약을 동시에 쉽게 개발하고 실행할 수 있도록 하기 위한 논점을 논의하기 위하여 팀을 만났습니다. 동시 실행과 관련된 문제에 익숙하다면 너는 아마도 모든 데이터가 단일 스레드를 통해 소유되어야 한다는 일반적인 규칙을 알고 있을 것입니다. 블록 체인의 관점에서 보면, 모든 계정이 자신의 데이터를 소유하고 있어야 한다는 것을 의미합니다. 데이터를 소유한다는 것은 비동시적인 메시지 전달을 제외하고 다른 실행 스레드가 데이터를 읽거나 쓸 수 없다는 사실을 의미합니다. 

  The Current Balance Problem

현재 잔액 문제 

Suppose you want to read the current balance of another contract, something that seems like it should be trivial. If the balance is “owned” by another account, say the currency contract, then your contract cannot “read it”. You could attempt to query it by asynchronous communication, but that would be liking sending your bank a letter asking for a balance update and waiting for a response in the mail. By the time you get the response (if you get a response), the balance may already be out of date.

당신이 되게 하찮아 보이는 어떤 계약의 현재 남아 있는 잔액을 보기 원한다고 가정해 봅시다. 잔액이 다른 계좌에 의해 "소유"된 경우, 통화 계약에 대해 말하자면 당신은 그 계약을 읽을 수 없다. 비동시적인 통신으로 조회를 시도 할 수도 있겠지만 은행에 보유 잔고 업데이트를 편지로 요청하고 메일로 응답을 기다리는 것과 똑같습니다. 응답을 받으면 (응답을 받는다면 말이다) 잔액이 이미 오래전에 것일 수밖에 없습니다.   

Fortunately, EOS makes it easy for one account to monitor all deposits and withdraws. In this case the reader contract would maintain its own logic duplicating the balance calculation and storage of the currency contract. This approach is also error prone because any small difference in behavior could result in your balance calculation differing from the currency contract.

운이 좋게도, EOS는 한 계좌가 모든 예금과 출금을 모니터하는 것을 쉽게 만듭니다. 이 경우, 읽고자 하는 사람의 계약은 통화 계약의 잔고 계산과 저장을 복제하는 자체 논리를 유지합니다. 이 방식은 행동의 작은 차이가 잔액 계산과 통화 계약을 다르게 할 수 있는 오류를 발생시키기 쉽습니다.    

        Another alternative is to use an oracle that will notify your contract of the balance while simultaneously delivering a message to the currency contract. The currency contract will reject the transaction if the oracle lied, therefore, your contact can trust the balance reported. Once again this only lets you know the balance for the split second your transaction is applied and creates a new problem that your transaction can be invalidated if other user actions are modifying your balance at the same instance. 

또 다른 대안은 통화 계약에 메시지를 전달하는 동시에 너의 계약 잔고를 알리는 오라클을 사용하는 것입니다. 오라클이 거짓말을 했다면 통화 계약은 거래를 거부 할 것이므로 당신은 보고된 잔액에 대하여 신뢰할 수 있다. 다시 한 번, 이것은 당신의 거래가 적용되는 순간의 잔액을 알 수 있게 하지만, 다른 사용자가 당신의 잔액을 수정하는 조치를 취하면 거래가 즉시 무효화될 수 있다는 새로운 문제를 만듭니다. 

     The underlying challenge here is that the balance data is owned by a different thread and therefore it cannot be reliably read and used when needed.여기에 있는 기본 문제는 잔고 데이터가 다른 스레드에 의해 소유되므로 정말로 필요로 할 때 안정적으로 읽고 사용할 수 없다는 것입니다.      Redefining the Problem문제를 재정의 하자!

under the above model, all data is owned by a single account and its code. This makes each account like its own blockchain and communication among accounts tricky. Fortunately, GPU developers have used another parallelization strategy: SMID - single instruction multiple data. Stated more generally, a GPU executes the exact same code over many independent instances of the data. Every pixel and/or vertex is modified by the same set of instructions.

위의 모델에서, 모든 데이터는 단일 계정과 코드에 의해 소유되게 됩니다. 이것은 각 계정이 그 자체가 블록 체인과 같은 것으로 만드는 것이기에 각 계정 간 통신을 까다롭게 만듭니다. 다행히도, GPU 개발자는 또 다른 동시화 전략 인 SMID (단일 실행 다중 데이터)를 사용했습니다. 더 포괄적으로 말하자면, GPU는 보다 많은 독립적인 데이터 인스턴스에서 똑같은 코드를 실행합니다. 모든 픽셀 그리고/또는 벌택스는은 동일한 명령어 집합로 수정됩니다.     

 Imagine for a moment that every account balance was represented as pixel in an image. Imagine that a smart contract was defined like a shader. A pixel shader can only write to a single pixel, but it can read from any number of other read-only sources.

모든 계정 잔고가 이미지의 픽셀로 표현되는 순간을 상상해보아라. 스마트 계약이 셰이더처럼 정의되었다고 상상해보십시오. 픽셀 셰이더는 단일 픽셀에만 쓸 수 있지만 그것을 다른 많은 읽기 전용 소스에서 읽을 수 있습니다.  

 Under this model a currency contract is not defined as code that operates on a mapping of account name to balance, but instead as code that operates on a single balance belonging to a single account. The currency contract would not be able to read other accounts balances, but it would know with certainty that all accounts were running the same code.

이 모델에서 통화 계약은 계정 이름을 잔고에 연결함으로써 작동하는 코드로 정의되는 것이 아니라 단일 계정에 속한 단일 잔고에서 작동하는 코드로 정의됩니다. 통화 계약은 다른 계좌 의 잔고를 읽을 수는 없지만 모든 계좌가 동일한 코드를 실행되고 있음은 확실히 알고 있습니다.   

   다음의 계약이 어떻게 보일 것인가?

void apply_simplecoin_transfer() { static Transfer message; static uint64_t balance = 0; load( thisContract(), “balance”, balance );  readMessage( message  ); requireNotify( {message.from, message.to} );  if( thisAccount() == message.to ) { balance += message.amount; } else if ( thisAccount() == message.from ) { assert( message.amount < balance, "insufficient funds" ) balance -= message.amount; }  if( balance ) store( “balance”, balance ); else remove( “balance”, balance );}

Notice there are a few subtle differences:

몇가지의 차이점이 있다는 것을 명심해라 

  The apply method only modifies a single balance

적용되는 메소드는 단일 잔고만 조정한다

The behavior of the contract depends upon the value of thisAccount()

thisAccount()의 가치에 따라 계약의 행동이 달라진다

The load() method takes an extra parameter specifying the current contractload()

 메소드는 현재의 계약을 세분화하는 여분의 변수를 사용한다

The store() and remove() methods always use the “balance” key rather than an account key.store()와 remove() 

메소드는 항상 계좌 키보다는 “잔고”키를 사용한다.

If we assume all accounts run this exact same code on their private data, we can still guarantee that there are no double spends. This is possible because every account requires both the sender and receiver to be notified of the message or the message will be rejected (both parties can be notified in parallel).

모든 계좌가 개인 정보를 통해 동일한 코드에서 작동한다고 가정하면 이중 지출이 없음을 보장 할 수 없습니다. 이는 모든 계정에서 발신자와 수신자가 메시지를 받아야하거나 메시지가 거부 될 수 있기 때문에 가능한 것입니다 (두 당사자가 동시에 통지 될 수 있다는 문제가 있습니다).  

 The receiver knows that the sender must have sufficient funds or the receiver will reject the message; therefore, the receiver can safely increment its own balance. Likewise, the sender knows the receiver will increment his balance so he decrements his own.

수신자는 보낸 사람이 충분한 자금이 있어야 된다는 사실을 알고 있고 그렇지 않으면 수신자가 메시지를 거부해야 한다는 것을 알고 있습니다. 그러므로 수신자는 안전하게 자신의 잔고를 증가시킬 수 있습니다. 마찬가지로 발신자는 수신자의 잔액을 늘리는 것은 자신의 금액을 줄이는 것을 알고 있습니다.    

  What does this give us?

이것이 우리에게 무엇을 알려줍니까?

Well now that we have this design pattern we have separated “code” from “data” in terms of parallelization. A single account can now run code provided by other accounts and the code provided by other accounts can now read all data belonging to an account.

뭐..우리는 동시화 측면에서 "데이터"의 "코드"를 분리하는 디자인 패턴을 가지고 있습니다. 단일 계정으로 다른 계정에서 제공하는 코드를 작동시킬 수 있으며 이제 다른 계정에서 제공된 코드로 계정에 속한 모든 데이터를 읽을 수 있게 됐습니다.  

    Suppose you wanted to build a social media platform where vote weight is proportional to current balance. This is something that requires the social media account to have the ability to read your balance and modify someone else’s post vote totals. In the ideal world it would be nice for @alice to vote for @bob while @sam is voting for @bill. This could be achieved as follows:

투표 가중치가 현재 잔고에 비례하는 소셜 미디어 플랫폼을 만들고 싶다고 가정해 봅시다. 이것은 소셜 미디어 계정이 당신의 잔고를 읽는 능력을 가지고 있고 다른 사람의 게시물 투표 총계를 수정할 수 있어야 합니다. 이상적인 세계에서, @alice가 @bob에 투표하는 동안에 @sam은 @bill에 투표하는 것이 이상적입니다. 이것은 다음과 같이 달성 될 수 있습니다 :  

 void apply_social_vote() { readMessage( vote ); if( vote.for == thisContract() ) { load( thisContract(), vote.postid, post ); post.totalvotes += vote.weight; store( vote.postid, post ); }   if( vote.voter == thisAccount() ) { static uint64_t balance = 0; load( "simplecoin", "balance", balance ); assert( balance >= vote.weight, “insufficient balance for vote weight” ); }}

In this case the contract code does two different things depending upon which data it is operating on. If it is operating on the receiver of the vote, then it increments the total votes. If it is operating on the sender, then it simply verifies the vote.weight <= the balance.

이 경우, 계약 코드는 그 코드가 작업 중인 데이터에 따라서 두 가지 다른 작업을 수행할 수 있습니다. 투표자가 수신자의 투표에서 작동중이라면 총 투표 수를 증가시킵니다. 그것이 송신자를 위해 작동 중이라면, 그것은 단순히 투표의 비중을 확인합니다. 비중 <= 잔고.  

    It should be noted that the vote receiver is still unable to read the vote giver’s balance. However, in this model two votes can be processed by 4 different accounts in parallel and it will work so long as the voter reports a vote weight that is accurate.

투표를 받는자는 아직 투표자의 잔액을 읽을 수 없다는 사실에 유의해야 합니다. 그러나, 이 모델에서는 2 개의 투표가 4 개의 다른 계좌로 동시에 처리될 수 있으며 투표자가 보다 정확한 투표 비중을 지속적으로 보고하는 한 이것은 계속 작동합니다. 

  While it may not be possible to read someone else’s balance while modifying your state, it is possible to read your own balance from the “simplecoin” contract from within the “social” contract.

당신의 상태를 수정하는 동안 다른 사람의 잔액을 읽는 것은 불가능하지만, "사회적"계약에서 "단순한"계약으로 부터 자신의 잔고를 읽을 수 있게 합니다.     

 What is everything so complicated?

복잡한 것이 도데체 무엇입니까?

As programmers we would love to read whatever we want, whenever we want, and let the computer figure things out. The naive approach is to simply put locks around data. If two people “happen” to read the data at the same time, then one will wait for the other. Unfortunately for blockchain developers, the outcome of these race conditions is not deterministic and therefore could break consensus. 프로그래머로서 우리는 원할 때마다 우리가 원하는 것을 읽을 수 있는 것을 좋아하고 컴퓨터가 원하는 것을 할 수 있도록 하는 것을 좋아합니다. 단순한 접근 방식은 데이터 주위에 단순히 잠금을 설정하는 것입니다. 두 사람이 동시에 데이터를 읽게 되면, 다른 한 사람은 데이터를 읽기 위해 기다리게 됩니다. 불행히도, 블록 체인 개발자의 경우 이러한 경쟁 조건의 결과가 결정적인 요소가 아니기 때문에 합의를 깨뜨릴 수 있습니다.  

  A New Hope

새로운 희망

There is a way to allow one account to read another account’s balance; the transaction can declare that it requires read access. The blockchain’s transaction scheduler can then ensure that no one that requires write access will execute code at the same time. Using the old approach to simplecoin (one contract owning all the data), this would create a lot of congestion around that contract as everyone needing to read would be blocking those who want to write and everyone would be bottlenecked by a single contract.

한 계정이 다른 계정의 잔액을 읽을 수 있도록 하는 방법이 있습니다 : 거래 그 자체가 읽기 권한이 필요하다고 선언 하는 것입니다. 블록 체인의 거래 스케줄러는 쓰기 권한이 필요한 사용자가 동시에 코드를 실행할 수 없도록 합니다. 단순한코인에 대한 오래된 접근법 (모든 데이터를 하나의 계약이 소유한 것)을 사용하면, 읽기를 원하는 누구나 쓰기를 원하는 사람을 차단할 것이고 그렇다면 모든 사람은 단일 계약으로 인해 병목 현상을 겪을 것이고 그렇다면 계약을 둘러싼 수많은 혼잡이 야기될 수 있습니다.     

 However, using the new approach to simplecoin, the probability that two transactions need to access the same account data at the same time is much lower. This will reduce lock contention and maximize throughput.

그러나, simplecoin에 대한 새로운 접근법을 사용하면, 두가지 거래가 동일한 계정 데이터에 동시에 접근해야 할 확률이 훨씬 낮아집니다. 이렇게 되면 잠금 경합이 줄어들고 처리량이 극대화됩니다.     

 Conclusion

결론

Parallelism is hard, especially when you need things to be deterministic while accessing shared data. Fortunately, there are solutions available and design patterns proven by those who design GPUs and computer graphics algorithms.

병렬 처리는 힘듭니다, 특히 공유된 데이터에 액세스하는 동안 결정적인 일이 필요할 때 특히 그러합니다. 운이 좋게도, GPU 및 컴퓨터 그래픽 알고리즘을 설계 한 사람들로부터 증명된 사용할 수 있는 해결책과 디자인 패턴이 있습니다.

      Disclaimer Nothing in this blog post should be construed to imply any particular feature or functionality of the EOS.IO software. All software designs subject to change as necessary. 면책 조항 : 블로그 게시물의 어떤 내용도 EOS.IO 소프트웨어의 특정 기능을 암시하는 것으로 해석되어서는 안됩니다. 모든 소프트웨어 디자인은 필요에 따라 변경 될 수 있습니다.

글이 맘에 드셨다면 보팅과 팔로우 부탁드립니다~