안녕하세요 마입니다. 이전 스팀 개발자였던 @dantheman 의 A better approach to Turing Complete Smart Contracts(튜링 완전 스마트 컨트랙트에 대한 더 나은 접근 방법)에 대한 번역을 해보았습니다.
이더리움 스마트 컨트랙트의 한계성과 앞으로의 스팀의 발전 가능성에 대해서 알 수 있었던 글입니다. 다만, 7개월 전의 글(2016년 10월)이기 때문에 현재 내용상 일부 변경된 사항은 있을 수 있지만 그의 글의 가치는변하지 않은 것 같습니다.
마찬가지로 기술적으로 복잡한 글이어서 관련 주석을 최대한 달아놨으며 모르시는 부분이 있으면 댓글을 다시면 최대한 협조해서 도와드리겠습니다.
튜링-완전 스마트 컨트랙트의 더 나은 접근 방법
이더리움은 범용 스마트 컨트랙트의 현재 표준이지만 이더리움을 개발하는데 시간을 투자 한 사람은 누구나 이더리움의 디자인에 있어서 매우 어려운 문제가 있다는 것을 알고 있습니다. 저는 지난주 새로운 튜링-완전 스마트 컨트랙트 시스템에 대한 개념 증명을 위해 작업을 하면서 시간을 보냈습니다. 그리고 그 과정에서 철학적 접근 방식에서 몇 가지 큰 차이점을 발견했습니다.
이더리움의 기술적 과제
내가 알아낸 것에 대한 세부 사항을 설명하기 전에, 이더리움 스마트 컨트랙트 개발자가 직면 한 기술적 문제가 뭔지 살펴봅시다.
1.성능
2016 년 2 월의 성능 분석에 따르면 Parity 이더리움 클라이언트는 6 개월 분의 트랜잭션 (1 백만 블록)을 처리하는 데 한시간 이상 걸렸습니다. 모든 1백만 블록은 이더리움 네트워크에 대한 최근의 서비스 거부 공격 이전에 있었습니다.
이러한 사실에 비교해서 볼만한 자료가 있습니다. 이더리움보다 훨씬 더 높은 평균 처리 속도로 600만 스팀 블록을 처리하는 데에는 단 몇 분밖에 걸리지 않습니다. 이는 처리 속도가 20 배이상 차이가 나는 것을 나타냅니다.
단일 CPU 스레드가 가상 기계(virtual machine)를 처리 할 수있는 속도는 네트워크의 잠재적 트랜잭션 처리량에 직접 영향을 줍니다. 현재 이더리움 네트워크는 초당 20건이 약간 넘는 트랜잭션을 처리 할 수 있습니다. 반면, 스팀은 초당 1000 회의 트랜잭션을 유지할 수 있습니다.
이더리움에 대한 최근의 공격으로 네트워크가 완전히 포화되고 다른 사람에게 서비스를 제공하는 것이 거부 됬었습니다. 반면에 스팀은 수수료 없이 서비스를 방해받지 않고 공격에서 살아남았습니다.
Parity 이더리움 클라이언트 : 레퍼런스 클라이언트인 geth 클라이언트의 대안 클라이언트
스레드(thread) : ①컴퓨터 프로그램 수행 시 프로세스 내부에 존재하는 수행 경로, 즉 일련의 실행 코드. 프로세스는 단순한 껍데기일 뿐, 실제 작업은 스레드가 담당한다. 프로세스 생성 시 하나의 주 스레드가 생성되어 대부분의 작업을 처리하고 주 스레드가 종료되면 프로세스도 종료된다. 하나의 운영 체계에서 여러 개의 프로세스가 동시에 실행되는 환경이 멀티태스킹이고, 하나의 프로세스 내에서 다수의 스레드가 동시에 수행되는 것이 멀티스레딩이다. ②나무 데이터 구조(tree data structure)에서 상위 노드의 식별과 나무 내의 정보 탐색을 촉진하는 포인터.
EVM (Ethereum Virtual Machine)이 느린 몇 가지 이유가 있습니다.
- 레벨 DB와 32바이트 키/값 쌍(32 byte key/value pairs)을 기반으로 스토리지 액세스
- 256비트 연산은 정상 계산에 대해 훨씬 느립니다.
- 가스 소비량을 계산하는 것은 합의(consensus)의 일부입니다.
- 스크립트의 내부 메모리 레이아웃 또한 합의의 일부입니다. (1번 참조)
- EVM 스크립트를 최적화할 수 있는 기회가 거의 없습니다.
EVM : Ethereum Virtual Machine. 탈중앙화된 튜링 완전 가상 기계이며, 공공 노드(public node)의 국제 네트워크를 이용하여 스크립트를 실행할 수 있다.
Level DB : LevelDB 는 Google 직원인 Jeffrey Dean 과 Sanjay Ghemawat가 작성한 오픈 소스 디스크 기반 키 - 값 저장소 입니다. Bigtable 에서 영감을 얻은 LevelDB는 새로운 BSD 라이센스 에 따라 GitHub 에서 호스팅되며 다양한 유닉스 기반 시스템, Mac OS X , Windows 및 Android 로 포팅되었습니다.
키 쌍(key pair) : 공개 키 암호 알고리듬에 사용되는 개인 키와 공개 키 쌍. 2개의 키는 서로 수학적인 방법에 의해 암호 및 복호 과정을 수행함으로써 원래의 평문을 추출할 수 있다. 개인 키와 공개 키 쌍은 1개는 암호화에 이용되고 또 다른 1개의 키는 복호화에 이용된다.
'무한한(Unlimited)' 확장성(Scalability) 주장
비탈릭 부테린(Vitalik Buterin)은 이더리움이 2년 이내에 "무한한" 확장성을 제공할꺼라고 주장합니다. 이 주장은 모든 노드가 모든 트랜잭션을 처리 할 필요가 없다는 아이디어에 기반합니다. 저는 이런 생각 때문에 실용적인 이유로 실패할 것이라고 생각합니다. 아래에서 얘기해 보겠습니다.
그들의 접근 방식은 블록체인을 "다중 스레드"로 만드는 방법으로 보여질 수 있는 블록체인을 "샤드(shard)"하는 것입니다. 각 노드는 "하나의 스레드"를 실행하고 각 "스레드"는 초당 20회의 트랜잭션을 처리 할 수 있습니다. 이론적으로 그들은 무제한의 노드를 추가 할 수 있으며 트랜잭션 볼륨은 무제한으로 확장될 수 있습니다.
두 개의 완전히 독립적인 스마트 컨트랙트가 있다고 가정해봅시다. 이 두 컨트랙트는 각각 초당 20 건의 트랜잭션으로 자체 샤드에서 실행될 수 있습니다. 그러나 이 두 컨트랙트가 서로 통신해야한다면 어떻게 될까요? 해결책은 하나의 컨트렉트에서 다른 컨트렉트로 메시지를 전달하는 것입니다. 메시지를 전달하는 다중 스레드 프로그램을 구현한 사람은 메시지 전달 오버 헤드에 대한 계산 값이 충분히 낮지 않으면 노력할 가치가 없다는 것을 알고 있습니다.
오버헤드(overhead) : 시스템의 요구 사항을 충족시키는 데 필요한 추가 설계 기능
인터넷을 통한 노드 간 메시지 전달 오버 헤드는 매우 높습니다. 암호 유효성 검사를 추가하면 상당한 오버 헤드가 발생합니다. 다른 샤드에서 하나의 값을 "읽는" "비용"은 중요합니다.
마지막으로 멀티 스레드 프로그램 개발자는 관리하는 데이터를 "소유"하고 있는 각 스레드에 대한 개념을 잘 알고 있습니다. 그 데이터에 접근하고 싶은 모든 것들은 데이터의 소유자를 통해서 가게 됩니다. 하나의 샤드가 초당 20 개 이상의 요청을 받는 데이터 조각을 소유하면 어떻게 되겠습니까? 어떤 시점에서 단일 스레드는 병목 현상을 겪게 됩니다.
"샤딩"으로 스팀을 구현하면 모든 투표에 영향을 미치는 "글로벌 상태"에 결국 병목 현상이 생길 것입니다. 시장 처리 제한 주문에 대해서도 동일한 결과가 발생합니다. 샤딩은 단순히 선형적으로 확장되지 않으며 무한하게 확장되지 않습니다.
2.가격
이더리움에서 코드를 실행하려면 컨트랙트들은 가스를 지불해야합니다. EVM은 실행되는 모든 명령을 계산하고 실행하는데 얼마나 가스가 드는지 계산하고 그것을 지불합니다. 컨트랙트에 가스가 다 떨어지면 컨트랙트에 의해 이루어진 모든 변경 사항은 되돌려 지지만 생산자는 여전히 가스 수수료를 책정합니다.
이더리움에 스팀과 같은 것을 구현하는 것은 사용자가 업보트(Vote)당 0.01 달러를 내야 되고 게시물당 더 많은 돈을 지불해야한다는 점이 주요한 문제입니다. 사용자 수가 증가함에 따라 네트워크가 포화 상태가 되어 가스의 가격이 상승하게 됩니다.
스팀이 이더리움에서 작동하는 유일한 응용 프로그램이 아니라고 상상해보십시오. Golos와 Augur가 각각 100만 명의 사용자에게 인기가 있다고 상상해보십시오. 가스의 가격은 세 가지 애플리케이션의 성장을 저해할 때까지 올라갈 것입니다.
가격을 낮추는 유일한 방법은 효율성을 향상시켜 트랜잭션 처리량을 늘리는 것입니다.
효율성을 향상시키는 것은 획일적인 과정이 아닙니다. 더 빠른 디스크를 설치해도 계산의 효율성은 향상되지 않습니다. 계산 속도를 높인다고 디스크 액세스에 도움이 되지 않습니다. 효율성을 향상 시키기 위한 모든 시도는 각 작업의 상대적인 가스 비용에 필연적으로 영향을 미치게 됩니다.
이더리움은 최근 가스 비용을 변경하기 위해 하드포크을 실행해야만 했습니다. 마지막으로 이더리움이 하드 포크가 된 결과가 이더리움 클래식이죠!
EVM을 최적화하려는 모든 시도가 운영의 상대 비용을 변경한다고 말하기는 어렵습니다. 가스 가격은 최소한의 최적화를 보이는 지침에 비례한 양만큼만 줄일 수 있습니다.
일부 지침을 최적화하면 블록 유효성 검사기의 순이익률이 증가 할 수 있지만 스마트 컨트랙트 개발자는 여전히 높은 가격을 지불해야합니다.
가스는 합의의 일부이기 때문에 모든 노드는 하드 포크가 발생할 때까지 이전에 사용한던 가스 가격 계산법을 사용하여 이전 블록을 계속 처리해야합니다. 이것은 미래에 최적화를 해도 이것이 원래 회계 방식을 유지할 필요성에 의해 제약된다는 것을 의미합니다.
3. 코드 최적화
가장 큰 최적화 소스 중 하나는 컴퓨터의 하드웨어를 개선하는 것이 아니라 소프트웨어를 개선하는 것입니다. 특히 컴파일러는 동일한 컴퓨터에서 실행되는 코드의 성능을 향상시키는 데 대단한 작업을 할 수 있습니다. 컴파일러는 프로그래머의 의도에 관한 더 많은 정보에 액세스 할 수 있기 때문에 최적화를 할 수 있습니다. 코드가 어셈블리로 변환되면 최적화를 위한 많은 기회를 잃게 됩니다.
어셈블리(assembly) : 상징적 기호 언어를 사용하여 작성한 프로그램을 기계어로 된 프로그램으로 번역하는 것.
누군가가 기본 구현(native implementation)을 제공하여 전체 컨트랙트를 최적화하려고한다고 가정 해보십시오. 기본 구현은 EVM에서 구동되지 않았기 때문에 기본 구현이 가스 비용을 계산하는 방법을 알지 못한다는 점을 제외하면 동일한 입력(inputs)이 주어진 모든 동일한 출력(outputs)을 발생시킵니다.
구현(implementation) : 일반적으로 시스템의 라이프 사이클은 시스템 계획, 설계, 시공, 테스트, 운용 단계로 나뉘어진다. 「구현」이란 계획하고 설계한 종이 위에 시스템을 현실적으로 운용할 수 있도록 하는 것으로, 장치 제조 · 설치 · 조정, 프로그래밍과 디버깅 등을 행하며 위의 시공에 해당하는 것이다.
4. 프로그래머 의도
이더리움 스마트 컨트랙트는 해석 프로그램(interpreter)이 처리하는 컴파일된 바이트 코드로 게시됩니다. 사람들이 스마트 컨트랙트를 처리하고 이해하기 위해 코드를 읽어야하지만 블록체인은 소스 코드를 저장하지 않고 어셈블리를 저장합니다. 사람들은** "컴파일 된 코드"**가 소스 코드의 예상 출력과 일치하는지 확인해야만 합니다.
이 접근 방식에는 몇 가지 문제점이 있습니다. 모든 컴파일러 개발자가 동일한 코드를 생성하고 동일한 최적화를 수행해야하거나 모든 컨트랙트를 선택한 컴파일러를 기준으로 유효성이 검사되어야합니다.
두 경우 모두 컴파일 된 코드는 컨트랙트 작성자의 명시된 의도에서 제거 된 하나의 단계(step)입니다. 컴파일러의 버그는 이제 프로그래머의 의도를 위반하게되고 합의(consensus)가 소스 코드를 알지 못하기 때문에 합의 해석을 수정하여 이러한 버그를 수정할 수 없습니다.
다른 접근법
C ++ 언어를 만든 사람은 동작을 구현하는 방법을 정의하지 않고 코드 블록의 예상 동작을 정의하는 철학을 가지고 있습니다. 즉, 서로 다른 컴파일러가 서로 다른 플랫폼에서 서로 다른 메모리 레이아웃을 가진 서로 다른 코드를 생성합니다.
또한 개발자는 표현하고자하는 것에 집중할 수 있으며 컴파일러 개발자 또는 기본 하드웨어에대한 불필요한 제한없이 기대하는 결과를 얻을 수 있음을 의미합니다. 따라서 사양을 준수하면서 성능을 최대한 최적화시킬 수 있게 됩니다.
개발자가 구동하길 원하는 코드를 게시하는 스마트 컨트랙트 플랫폼을 상상해보십시오. 블록체인 합의는 코드의 적절한 해석에 달려 있지만 코드 실행 방법에 구속되지는 않습니다.
이 예제에서 스크립트는 다른 알고리즘을 사용하여 미리 컴파일 된 바이너리로 대체 될 수 있으며 블랙 박스의 입력과 출력이 동일하게 유지되는 한 모든 것이 정상입니다. 이것은 블랙 박스가 얼마나 많은 가스가 소비되었는지를 정확하게 계산해야하기 때문에 이더리움에서는 불가능합니다.
블랙 박스 : 입력과 출력이 일어나는 장치 혹은 시스템.
가스에 대한 더 나은 접근법
가스는 결정론적으로 실행 시간을 계산하기위한 대강의 접근 방식입니다. 이상적인 세상에서는 벽 시간을 사용하기만하지만 사양과 부하가 다른 컴퓨터들은 모두 다른 결과를 얻습니다. 일정한 시간이 얼마나 걸리는지에 대한 결정적 합의에 도달하는 것이 불가능할 수도 있지만, 거래를 포함해야하는지의 여부에 대한 합의에 는 도달할 수 있어야합니다.
벽시간(wall clock time) : 팔목시계나 벽시계와 같은 정밀시계로 결정하는 경과 시간. 마이크로프로세서 클록과 구분되는 것으로, 마이크로프로세서 클록은 초당 클록 펄스 수가 마이크로프로세서 클록 속도를 좌우하는 일정한 주파수 펄스의 신호 발생기이다. 벽 시간은 마이크로프로세서 클록이 아닌 컴퓨팅에서 단일 프로그램이나 다중 프로그램 수행시 각 프로그램이 수행하는 실제 시간을 말하며, 총 경과 시간을 일, 시, 분, 초(dd+hh:mm:ss)로 표시한다.
거래를 포함할지말지에 대한 합의에 도달하려고 시도하는 방안에 몰려있는 많은 사람들을 상상해보십시오. 그들 각각은 트랜잭션을 처리하는 데 걸리는 벽 시간을 측정하고 선점 스케줄링(preemptive scheduling)을 사용하면서 실행이 너무 오래 걸리는 경우 실행을 중단합니다.
선점 스케줄링 : 시분할 시스템에서 타임 슬라이스가 소진되었거나, 인터럽트나 시스템 호출 종료시에 더 높은 우선 순위 프로세스가 발생 되었음을 알았을 때, 현 실행 프로세스로부터 강제로 CPU를 회수하는 것을 말한다.
측정을 한 후 모두 투표를하고 대부분이 "ok"라고 말하면 모든 사람이 거래를 포함합니다. 네트워크는 "소요 시간"을 모릅니다. 거래가 시간의 승인된 양만큼 걸렸다는 것만 알고 있습니다. 개별 컴퓨터는 합의에 도달했다는 것을 알게되면 시간이 얼마나 소요되는지와 무관하게 거래를 실행합니다.
컨센서스 관점에서 볼 때, 이것은 모든 스크립트가 행해진 실제 계산과 상관없이 동일한 수수료를 지불한다는 것을 의미합니다. 스크립트는 "계산"에 지불하는 것이 아니라 "고정된 길이의 시간 조각"에 지불하고 있습니다. 운영 체제 개발자가 익숙할 수 있다는 점에서 스크립트는 할당된 퀀텀 내에서 실행되어야합니다. 그렇지 않으면 선점되고 해당 작업이 손실됩니다.
위의 접근 방식은 매우 추상적이어서 직접 투표 구현에서는 실용적이지 않지만 현재 스팀에서 사용하는 것보다 훨씬 많은 오버 헤드없이 확장 할 수있는 방법이 있습니다. 우선, 모든 블록 생산자는 블록을 생산하기위한 긴박한 일정에 처해 있습니다. 그들이 시간을 놓치면 다음 증인으로 넘어갈 것입니다. 즉, 블록 제작자는 블록을 적용하고 다음 블록 시간 전에 네트워크를 통해 대부분의 노드 (다음 증인(witness)를 포함하여)로 전파 할 수 있어야합니다.
즉, 블록에 트랜잭션이 존재한다는 것은 네트워크가 블록과 모든 트랜잭션을 제 때 처리할 수 있었다는 신호입니다. 네트워크의 각 노드는 블록과 트랜잭션이 처리하는 데 걸린 시간에 대한 "투표"를 받습니다. 실제로 트랜잭션이 할당 시간을 초과했다고 생각하면 노드는 블록을 중계(relay)할 필요가 없습니다.
인식된 실행 시간을 기반으로 블록을 차단하는 노드는 여전히 인식된 "불량"블록 위에 쌓이는 새로운 블록을 받아들일 것입니다. 어떤 시점에서 노드는 더 긴 포크(long fork)와 스위치를 가로 질러 오거나 "불량"블록이 돌이킬 수없는 충분한 확인(투표)하에 묻힐 것입니다. 일단 되돌릴 수 없는 상황이 되면 노드는 그 블록과 그 이후의 모든 것을 중계(relay)하기 시작할 것입니다.
보상 받기를 원하는 블록 제작자는 자신의 블록이 전파되고 다른 노드가 가질 벽 시계 추정치에서 "보수적인"것이되도록 할 것입니다. 네트워크는 포함 된 트랜잭션의 수에 비례하여 블록 보상을 조정해야합니다.
귀속지분(vesting stake)당 대역폭/퀀텀(bandwidth / quantum)에 의해 강화 된 "속도 제한"때문에 보너스를 수집하기 위해 각각 마이너가 자신의 블록을 채울 큰 지분(stake)이 필요할 것입니다.
서비스 거부(DOS) 방지
스크립트의 문제점 중 하나는 공격자가 무한 루프를 생성하는 데 드는 비용이 들지 않는다는 것입니다. 최종 결론은 스크립트를 거부하는 경우에도 노드 유효성 검사는 리소스를 소비하게됩니다. 이 경우 유효성 검사기는 소비 한 리소스에 대해 대가를받지 않습니다.
검사기가 이러한 종류의 남용 사항을 처리 할 수있는 두 가지 방법이 있습니다.
- 로컬 블랙리스트 / 화이트리스트 스크립트, 계정 및 / 또는 동료
- 각 스크립트에 작업 증명(POW) 필요
작업 증명을 사용하여 유효성 검사기가 스크립트 제작자가 최소한의 노력을 소비했음을 알 수 있습니다. 작업이 많을수록 유효성 검사기가 스크립트가 최대 한도까지 실행할 수있는 "벽시계"시간이 길어집니다. 계산 비용이 많이 드는 트랜잭션을 전파하려는 사람은 비용이 적게 드는 트랜잭션을 생성하는 사람보다 더 어려운 작업 증명을 생성해야합니다.
이 작업 증명과 TaPoS (지분 증명으로서의 거래)가 결합 됨으로써 우리는 전체 네트워크를 공동으로 보호하는 작업 증명으로서의 트랜잭션을 갖게되었습니다. 이 접근법은 증인이 "자신의 블록을 채워서" 돈을 받는 것을 막는 부수적인 효과가 있습니다. 왜냐하면 그들이 생성하는 각각의 거래에는 작업 증명이 필요하기 때문입니다. 따라서 블록체인은 스크립트 실행의 어려움에 대한 객관적 프록시로서 작업 증명의 어려움을 토대로 트랜잭션에 대한 증인에게 보상할 수 있습니다.
나는 최근에 실험적 블록체인 운영과 통합 된 Wren 스크립팅 언어를 사용하여 몇 가지 코드를 개발했습니다. 단일 스마트 컨트랙트에서 기본 "암호화 통화"를 구현하는 방법은 다음과 같습니다.
test_script = R"
class SimpleCoin {
static transfer( from, to, amount ) {
var from_balance = 0
var to_balance = 0
if( from != Db.current_account_authority().toString )
Fiber.abort( "invalid authority" )
var a = Num.fromString( amount )
if( a < 0 ) Fiber.abort( "cannot transfer negative balance" )
if( Db.has( from ) )
from_balance = Num.fromString(Db.fetch( from ))
if( Db.has( to ) )
to_balance = Num.fromString(Db.fetch( to ))
if( from_balance <= 0 && Db.script_account().toString != from)
Fiber.abort( "insufficient balance" )
from_balance = from_balance - a
to_balance = to_balance + a
Db.store( from, from_balance.toString )
Db.store( to, to_balance.toString )
}
}
)";
trx.operations.emplace_back( set_script{ 0, test_script } );
trx.operations.emplace_back(
call_script{
account_authority_level{1,1}, 0,
"SimpleCoin",
"transfer(_,_,_)", {"1","0","33"}
}
);
두 개의 블록체인 레벨 연산인 set_script와 call_script를 소개했습니다. 첫 번째 작업은 스크립트를 계정 (계정 0)에 할당하고 두 번째 작업은 스크립트로 정의 된 메서드를 호출합니다.
스크립팅 환경은 Db API를 통해 블록체인 상태에 액세스 할 수 있습니다. 이 API를 통해 스크립트 특정 데이터 뿐만 아니라 작업의 현재 권한 수준에 대한 쿼리 정보(다음 정보)를 로드하고 저장할 수 있습니다. call_script 운영은 "계정 1"권한 레벨 "1", 즉 활성 권한이 호출을 승인했음을 주장합니다. 그런 다음 "account 0"에서 스크립트를 호출하고 SimpleCoin.transfer ( "1", "0", "33")를 호출합니다.
전달 메소드는 current_account_authority가 전송 호출의 시작 필드와 일치하는지 확인할 수 있습니다.
개념 증명의 벤치 마크
저는 각각 1000개의 트랜잭션을 처리하여 'SimpleCoin.transfer'에 대한 각각의 단일 호출을 포함하고 실행에 걸린 시간을 측정했습니다. 모두 합해서, 나의 기계는 해석 프로그램(interpreter)를 통해 초당 1100건 이상의 트랜잭션을 처리 할 수있었습니다. 이 성능 수준은 스크립트의 최적화 및 / 또는 캐싱보다 우선합니다. 즉, 초당 측정 된 1100건의 트랜잭션에는 스크립트를 1100번 컴파일하는 작업이 포함되었습니다. 더 똑똑한 구현은 컴파일 된 코드를 크게 개선 할 수 있도록 캐시합니다.
이런 사실을 잘 보여주는 자료가 있습니다. 이더리움 "Unlimited"가 완벽하게 확장(scaled)되었다고 가정하도, 저의 단일 노드가 방금 처리한 동일한 트랜잭션을 처리하기 위해 55개의 노드가 필요합니다. Wren이 적절한 캐싱으로 최적화되고 이더리움이 필요한 동기화 오버 헤드를 위해 가격이 더 저렴해진다면, 스팀과 Wren 기술을 기반으로 한 스마트 컨트랙트 플랫폼이 이더리움보다 수백 배 더 효율적일 수 있습니다.
스마트 컨트랙트를 튜링해야하는 이유
분산된 거버넌스는 탈 중앙화된 컨트랙트 시행에 영향을받습니다. 블록체인은 유익할만한 모든 컨트랙트를 사전에 알 수 없으며, 새로운 스마트 컨트랙트를 지원하기위한 하드 포크의 정치적 중앙 집중 요구 사항은 '어떻게 작동하는가'에 대해 유기적으로 발견할 수있는 능력을 제한합니다.
적절한 스마트 컨트랙트 엔진을 사용하면 개발자는 "저성능 스크립트"를 실험한 다음 "저속 스크립트"를 동일한 블랙 박스 인터페이스를 준수하는 고성능 구현으로 교체 할 수 있습니다. 결정적으로 가스 및 메모리 레이아웃을 계산할 필요없이도 원하는 성능 향상을 실현할 수 있습니다.
결론
설명된 스마트 컨트랙트 설계와 결합된 스팀의 기술은 스마트 컨트랙트를 실행하기위한 거래 수수료를 완전히 제거하면서 이더리움보다 수백배 확장 될 것입니다. 이더리움에서 경제적인 이유로 실행 가능하지 않은 수천 개의 새로운 응용 프로그램을 열 수 있습니다.
오늘 포스팅 도움이 많이 되셨나요?
도움이 되셨다면 Steemit에 가입해서 하단 
버튼을 눌러주세요~!
좋은글 감사합니다..
하지만 봐도 모른다는^^
이글을 보고 생각드는건 보스코인 박창기대표가 한 말중에 대중은 어떤시스템인지 어떤엔진으로 되는건지 몰라도 된다. 그냥 사용하기 편하면 되는건데...
저같은 사람을 두고 하는이야기고 저도 공함하는 부분이었습니다.^^
마크다운 에디터에서 소스코드를 쓸 때
들여쓰기도 되고 좋습니다.
ㅠㅠㅠㅠㅠ 감사합니다 모닝님 이걸 몰라서 헤맸어요ㅠㅠ
💆👲....
https://steemit.com/blockchain/@dantheman/a-better-approach-to-turing-complete-smart-contracts
this link is original :)
Lol...
you got me,i didnt want to complain about interpretations.....will check it out now.
Thanks for sharing @maa
Upvote and Resteem.!!
thank you @akiyoshi !! :)
You are welcome 😊😉
Applause 👏
gj@
좋은글 감사합니다~^^
어렵네요 ㅎㅎ
내용이 많이 어렵지만, 핵심적인 내용을 요약해드리자면
이더리움의 댑이 가지고 있는 기술적 결함이 있으며, 대표적인 것이 댑이 많아지면 많아질수록 가스비용이 증가하여 이것으로 인해 문제가 생기고 이것을 고치려면 하드포크까지 해야하는 상황이 올텐데(물론 지금 아라곤으로 해결하려고하고는 있지만)
스팀은 수수료없이 더 깔끔하게 구동이 가능하다는 얘기입니다. ㅎㅎ
좋은 글 감사합니다.
저는 지금 현재로서 ETH가 직면한 문제중 가장 큰 문제라고 생각합니다.
지금 메트로폴리스가 문제가 아닙니다.
ICO로 dApp이 쏟아져 나오고 있는데... 가스비 나중에 어떻게 할지..
근데 이미... ETH 기반 dApp ICO 투자를 벌써 10개 이상했다는.. ㅠ.ㅠ
하아.. 비탈릭 너만 믿는다 ㅠ.ㅠ
ㅎㅎ 비탈릭 ㅠ_ㅠ 공공재입니다
영양가 높은 글을 번역해두셔서 감사합니다. 덕분에 많이 배워갑니다
감사합니다 :)
천천히 읽어봐야겠네요. 번역 고맙습니다.
내용이 많이 어려운 것 같습니다... 댄 너란 남자...
좋은 글 감사합니다! :)
읽어주셔서 감사합니다!!
어후.. 기술적인 접근이라.. 하는업이 이쪽인데도 이해하기 힘드네요 장문의 정보글 감사합니다.
번역 감사드립니다!!