오늘 EOS가 어떻게 동작하는지 그리고 개발자가 어플리케이션을 개발하는 방법에 대한 이야기를 함께 처음으로 조금이나마 나눌 수 있어서 기쁘게 생각합니다.
추상화된 수준의 소개 (High Level Introduction)
EOS는 서로간 메시지를 주고 받는 사람들의 그룹 및 또는 스크립트(봇) 그룹과 같이 구성됩니다. 모든 사용자 또는 봇이 계정을 가지고 있는 이메일 시스템으로 생각될 수 있습니다.
이메일처럼 메시지에는 보낸 사람, 받는 사람 그리고 잠재적으로 메시지에 복사 된 몇 개의 계정이 있습니다. 또한 이메일과 같이 메시지가 발송되었다는 것만으로 메시지가 전달되었다는 것을 보장하지는 않습니다. 메시지를 전달하는 것은 수신자가 메시지를 수락하고 수신자 코드에 따라 메시지를 처리했음을 의미합니다.
이메일과 달리 받는 사람과 메시지에 복사 된 모든 계정은 메시지를 거부 할 수 있으며, 이 경우에는 메시지가 전달되지 않습니다.
EOS 블록체인은 주소가 지정된 모든 계정에 성공적으로 전달된 모든 메시지를 투명하고 영구적으로 로그를 남기지만 봇에 의해 생성된 보내는 메시지를 포함 할 수도 있습니다.
바이너리(Binary)가 아닌 퍼블리시 코드(Publish Code)
"봇"이라고 서술 할 때 이는 블록체인 위에 게시된 자체 실행 소스 코드(Self-executing source)를 의미합니다. 계정 (일명 어플리케이션 또는 스마트 컨트랙트)는 상태(State)를 읽고 저장할 수 있고 또는 다른 계정에 비동기적으로 보내는 새 메시지를 생성 할 수 있는 메시지 처리기(handlers)의 집합입니다. 모든 계정의 상태가 비공개이며 다른 계정에서는 접근할 수 없으므로 다른 여러 계정에서 병렬로 메시지를 처리 할 수 있습니다.
어플리케이션의 구조
모든 계정 (일명 어플리케이션)에는 테이블 당 여러 개의 정렬 된 인덱스가 있는 임의의 수의 테이블을 정의 할 수 있는 자체 비공개 데이터베이스가 있습니다. 이러한 데이터베이스 테이블은 어플리케이션의 상태를 저장하는 데 사용됩니다. 이 상태는 범용 블록 탐색기가 모든 컨트랙트의 상태를 의미있는 방식으로 나타낼 수 있도록 하는 스키마(Schema)로 설명됩니다.
모든 계정은 구조(Structs)라고 불리는 많은 유형을 정의 할 수 있습니다. 이 구조는 메시지의 이진 직렬화(Binary Serialization)를 정의하고, 누구나 이진 표현(Binary representations)을 인간이 읽을 수 있는 표준 JSON 표현과, 표준 JSON 표현으로 부터 변환 할 수 있게 합니다. 이를 통해 효율적으로 바이너리 인코딩을 하면서 블록 체인을 투명하게 유지할 수 있습니다.
마지막으로 모든 계정은 다른 계정으로 전달되는 메시지에 복사 될 때 수행하고자 하는 작업(Action)을 정의 할 수 있습니다. 예를 들어, 전달(Transfer) 메시지가 통화(Currency) 어플리케이션에 전달되고 거래 어플리케이션이 수령일 경우 거래소는 예금을 처리해야 합니다.
통화 어플리케이션 예제
가장 간단한 어플리케이션 중 하나는 화폐입니다. 이 예제는 EOS에서 화폐 어플리케이션이 어떻게 구성되는지에 대한 방법을 설명합니다.
책임의 한정
다음 예제 코드는 개념 설명 목적만을 위한 것이며 최종 구현 세부 사항은 다를 것입니다.
기본적인 통화 컨트랙트
어플리케이션을 작성할 때 액터(Actors)(일명 계정)가 취한 동작을 자신에게 묻는 것으로 시작한 후, 이러한 조치에서 파생된 데이터를 저장하고 색인화하는 데이터베이스 스키마를 정의합니다. 이러한 것들을 정의한 후, 들어오는 동작을 기반으로 데이터베이스 상태를 변환하는 논리를 명시합니다. 마지막으로 메시지 처리기를 권한 그룹에 그룹화합니다 (선택 사항).
통화를 구현하는 간단한 고급 어플리케이션을 살펴 봅시다. 통화는 소유자를 그들의 잔액에 매핑하는 테이블로 나타낼 수 있습니다. 잔액 소유자가 자금을 다른 계좌로 이체 할 수 있게 하며, 계좌에 잔액이 존재하지 않을 경우 새롭게 생성합니다. 자신에게 돈을 송금하는 것을 금지해야 하며, 전달 된 금액이 0보다 커야 합니다. 최초의 모든 돈은 컨트랙트 자체 계좌의 소유입니다. 잔액이 0에 도달하면 계정의 잔액 기록은 삭제되어야 합니다.
struct Transfer
to AccountName
from AccountName
amount UInt64
struct Init
table Balance
owner AccountName
balance UInt64
on Init action
precondition:
eos.requireAuthority( eos.thisAccount() )
eos.require( !Balance.find( eos.thisAccount() ) ) /// only call once
apply:
self = Balance.new()
self.owner = eos.thisAccount()
self.balance = 100000 /// maximum currency supply
Balance.save(self)
on Transfer action
validate:
// static validation, verifies action is internally consistent
// no access to database tables
eos.require( action.amount > 0 )
eos.require( action.to != action.from )
eos.requireNotify( action.to )
precondition:
// identify possible precondition check that can
// be executed with readonly access
eos.require( Balance[action.from].balance >= action.amount )
eos.requireAuthority( action.from )
apply:
// assuming all prior steps pass, perform the state transition
// that updates balances and/or creates a new account for receiver
var from = Balance[message.from]
var to = Balance.find( action.to )
if( !to ) {
to = Balance.new()
to.owner = action.to
}
from.balance = from.balance - action.amount
to.balance = to.balance + action.amount
Balance.save(to)
if( from.balance > 0 )
Balance.save(from)
else if( from != eos.thisAccount() )
Balance.delete(from)
주의할 사항
이벤트 처리기는 유효성 검증(Validate), 사전 조건(Precondition) 및 적용(Apply)의 세 부분으로 나뉩니다. 이러한 여러 섹션은 성능 최적화와 병렬 처리를 가능하게 하는 명확하게 다른 여러 단계로 프로세싱을 구분합니다. 유효성 검증 및 사전 조건 체크는 모두 읽기 전용이므로 병렬로 처리 될 수 있음을 의미합니다.
적용 단계는 사전 검증 된 조치(Pre-verified actions)의 실행 기록에서 현재 데이터베이스 상태를 재생성하기 위해 수행해야 하는 유일한 부분입니다. 이는 유효성 및 사전 조건에서 처리 하는것이 적용에서 처리하는 것보다 계산을 처리하는 것이 훨씬 저렴하기 때문에 중요합니다. 블록은 되돌릴 수 없는 유효성 검사로 간주되고 사전검사는 다시 수행 할 필요가 없는 반면 적용은 블록 체인이 동기화 될 때마다 결정적 상태(Deterministic State)를 생성하기 위해 실행해야 합니다.
계속 관심을 가져주세요
분산 어플리케이션이 EOS에서 커뮤케이션하는 방법에 대한 자세한 내용을 확인해 주십시오. 또한 http://eos.io의 메일링 리스트에 가입하는 것을 잊지 마십시오.
--