EOS EOSIO DApp 개발 – '나도 백서 읽는다' 시리즈 8. Scripts & Virtual Machines

Scripts & Virtual Machines

The EOS.IO software will be first and foremost a platform for coordinating the delivery of authenticated messages (called Actions) to accounts. The details of scripting language and virtual machine are implementation specific details that are mostly independent from the design of the EOS.IO technology. Any language or virtual machine that is deterministic and properly sandboxed with sufficient performance can be integrated with the EOS.IO software API.

액션에 계정 권한을 엮었어. 그래서 인증된 액션만 수행할 수 있도록 했어. 자랑할 만하지.
스크립트 언어와 가상 머신은 다른 기술과는 독립적이 되도록 해 놨어. 그래서 다른 언어나 다른 가상머신도 조건만 맞으면 사용할 수 있어. 앞으로 다른 언어나 다른 가상머신도 사용할 수 있게 하겠다는 거지.

Schema Defined Actions

All Actions sent between accounts are defined by a schema which is part of the blockchain consensus state. This schema allows seamless conversion between binary and JSON representation of the Actions.

액션구조에 대한 스키마가 정의되어 있어. 그래서 바이너리나 JSON으로 표현이 가능하고 서로 변환도 가능해.

Schema Defined Database

Database state is also defined using a similar schema. This ensures that all data stored by all applications is in a format that can be interpreted as human readable JSON but stored and manipulated with the efficiency of binary.

데이터베이스도 그렇게 했어. 그래서 바이너리 형태로 저장되고 다뤄지는 데이터를 JSON으로 해석할 수도 있어.

Generic Multi Index Database API

Developing smart contracts requires a defined database schema to track, store, and find data. Developers commonly need the same data sorted or indexed by multiple fields and to maintain consistency among all the indices.

계약에서 데이터를 읽고 쓸 수 있도록 데이터베이스를 제공해 줘. 데이터베이스를 사용하려면 스키마를 정의할 수 있는 방법과 데이터베이스에 접근할 수 있는 방법이 필요하지. 스키마는 구조체로 정의할 수 있도록 하고, 데이터베이스에 접근할 수 있도록 API도 제공해 줘. 여기서 강조하고 싶은 것 하나 - 다중 인덱스가 가능하다는 것.

Separating Authentication from Application

To maximize parallelization opportunities and minimize the computational debt associated with regenerating application state from the transaction log, EOS.IO software separates validation logic into three sections:
1.Validating that an Action is internally consistent;
2.Validating that all preconditions are valid; and
3.Modifying the application state.

병행처리 가능성과 계산 효율성을 위해 액션의 로직에서 서로 독립적으로 수행될 수 있는 것들을 분리할 필요가 있지. 액션의 내부적인 일관성을 검증하거나 선행조건을 검증하는 것이나 앱 상태를 변경하는 것은 서로 독립적이어서 분리 할 수 있어.

Validating the internal consistency of a Action is read-only and requires no access to blockchain state. This means that it can be performed with maximum parallelism. Validating preconditions, such as required balance, is read-only and therefore can also benefit from parallelism. Only modification of application state requires write access and must be processed sequentially for each application.

액션의 내부적 일관성을 검증하는 것은 읽기 전용이고 블록체인 상태에 접근할 필요가 없어. 병행처리할 수 있다는 거지. 선행조건을 검증하는 것도 읽기 전용이고 병행처리 가능해. 앱 상태를 수정하는 것만 쓰기가 요구되고 순차적인 처리가 요구 돼.

Authentication is the read-only process of verifying that an Action can be applied. Application is actually doing the work. In real time both calculations are required to be performed, however once a transaction is included in the blockchain it is no longer necessary to perform the authentication operations.

인증은 선행조건 검증에 해당하는 것으로 액션을 수행할 수 있는 권한이 있는지를 확인하는 것으로 읽기 전용 프로세스야. 이 조건이 만족되면 액션은 자신이 해야 할 일을 수행하지. 둘은 실시간으로 수행되지만 일단 트랜잭션이 블록체인에 포함되고 나면 더 이상 인증을 수행할 필요가 없어지지.