docs: translate ko/spec/ics-018-relayer-algorithms/README.md #24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hihiboss
reviewed
Jan 5, 2020
|
|
||
| *relayer*란 IBC 프로토콜을 이용하는 원장의 상태를 읽고 원장에 트랜잭션을 보내는 off-chain 프로세스입니다. | ||
|
|
||
| ### 요구 속성 |
There was a problem hiding this comment.
Suggested change
| ### 요구 속성 | |
| ### 지향 속성 |
|
|
||
| Relayer 알고리즘은 IBC의 "물리적인" 연결 계층입니다. 이 알고리즘은 IBC 프로토콜을 실행하는 두 체인 사이에 정보를 전달(중계)하는 off-chain 프로세스로, 프로토콜에서 허용하는 대로 각 체인의 상태를 살펴보고, 적절한 데이터그램을 만들며, 이를 상대 체인에서 실행합니다. | ||
|
|
||
| ### 동기 |
|
|
||
| ### 동기 | ||
|
|
||
| IBC 프로토콜에서, 블록체인은 다른 체인으로 특정 정보를 보낸다는 *의도*만을 기록합니다 — 즉 블록체인은 네트워크 전송 계층에 직접 접근하지 않습니다. 물리적인 데이터그램의 전달은 TCP/IP와 같은 전송 계층에 접근하는 off-chain 인프라가 수행해야 합니다. 이 표준은 *relayer* 알고리즘의 개념을 정의하며, 알고리즘은 체인간 중계를 수행하기 위하여 체인의 상태를 질의할 수 있는 off-chain 프로세스에 의해 실행됩니다. |
There was a problem hiding this comment.
Suggested change
| IBC 프로토콜에서, 블록체인은 다른 체인으로 특정 정보를 보낸다는 *의도*만을 기록합니다 — 즉 블록체인은 네트워크 전송 계층에 직접 접근하지 않습니다. 물리적인 데이터그램의 전달은 TCP/IP와 같은 전송 계층에 접근하는 off-chain 인프라가 수행해야 합니다. 이 표준은 *relayer* 알고리즘의 개념을 정의하며, 알고리즘은 체인간 중계를 수행하기 위하여 체인의 상태를 질의할 수 있는 off-chain 프로세스에 의해 실행됩니다. | |
| IBC 프로토콜에서, 블록체인은 다른 체인으로 특정 정보를 보낸다는 *의도*만을 기록합니다 — 즉 블록체인은 네트워크 전송 계층에 직접 접근하지 않습니다. 물리적인 데이터그램의 전달은 TCP/IP와 같은 전송 계층에 접근하는 off-chain 인프라가 수행해야 합니다. 이 표준은 *relayer* 알고리즘의 개념을 정의하며, 알고리즘은 체인의 상태 질의와 체인간 중계를 수행을 할 수 있는 off-chain 프로세스에 의해 실행됩니다. |
| - Relayer가 비잔틴이라고 가정하면, IBC의 안전 속성인 '정확히-한번(exactly-once)'이나 '전달-또는-시간초과(deliver-or-timeout)'는 relayer 행동에 의존하면 안 됩니다. | ||
| - IBC의 패킷 전달의 liveness는 최소 하나의 올바른 live 상태의 relayer의 존재에만 의존해야 합니다. | ||
| - 전달은 권한에 관계 없이 일어나야 하며, 필요한 모든 검증은 on-chain에서 수행되어야 합니다. | ||
| - IBC 사용자와 relayer 사이 소통의 필요성은 최소화해야 합니다. |
There was a problem hiding this comment.
Suggested change
| - IBC 사용자와 relayer 사이 소통의 필요성은 최소화해야 합니다. | |
| - IBC 사용자와 relayer 사이 통신의 필요성은 최소화해야 합니다. |
|
|
||
| `submitDatagram`은 체인마다 정의된 (일종의 트랜잭션을 제출하는) 절차입니다. 여러 데이터그램은 각각 하나의 트랜잭션으로, 또는 체인이 지원하는 경우 원자성을 가지고 하나의 트랜잭션으로 제출될 수 있습니다. | ||
|
|
||
| Relayer는 `relay`를 자주 호출합니다. 어떤 체인에서든 블록당 한번 이상 발생하지는 않으며, relayer가 얼마나 자주 중계하는지에 따라 아마 이보다는 덜 자주 발생합니다. |
There was a problem hiding this comment.
Suggested change
| Relayer는 `relay`를 자주 호출합니다. 어떤 체인에서든 블록당 한번 이상 발생하지는 않으며, relayer가 얼마나 자주 중계하는지에 따라 아마 이보다는 덜 자주 발생합니다. | |
| Relayer는 `relay`를 자주 호출합니다. 어떤 체인에서든 블록당 한번 이상 발생하지는 않으며, relayer가 얼마나 자주 중계하는지에 따라 덜 자주 발생할 수 있습니다. |
|
|
||
| ### 순서 결정의 제약 사항 | ||
|
|
||
| Relayer 프로세스에는 데이터그램을 어떤 순서로 제출할지 결정할 때 고려하는 암시적인 순서 결정의 제약 사항이 있습니다. 예를 들어, 패킷이 전달되기 전에 light client의 특정 블록 높이에 저장된 합의 상태와 commitment root를 완결시키기 위하여 헤더가 제출되어야 합니다. Relay 프로세스는 무엇을 언제 전달할지를 결정하기 위하여 해당 체인의 상태를 자주 질의할 의무가 있습니다. |
There was a problem hiding this comment.
Suggested change
| Relayer 프로세스에는 데이터그램을 어떤 순서로 제출할지 결정할 때 고려하는 암시적인 순서 결정의 제약 사항이 있습니다. 예를 들어, 패킷이 전달되기 전에 light client의 특정 블록 높이에 저장된 합의 상태와 commitment root를 완결시키기 위하여 헤더가 제출되어야 합니다. Relay 프로세스는 무엇을 언제 전달할지를 결정하기 위하여 해당 체인의 상태를 자주 질의할 의무가 있습니다. | |
| Relayer 프로세스에는 데이터그램을 어떤 순서로 제출할지 결정할 때 고려하는 암시적인 순서 결정의 제약 사항이 있습니다. 예를 들어, 패킷이 전달되기 전에 light client의 특정 블록 높이에 저장된 합의 상태와 commitment root를 완결시키기 위하여 헤더가 제출되어야 합니다. Relayer 프로세스는 무엇을 언제 전달할지를 결정하기 위하여 해당 체인의 상태를 자주 질의할 의무가 있습니다. |
|
|
||
| ### 장려금 및 보상 (Incentivisation) | ||
|
|
||
| Relay 프로세스는 트랜잭션 수수료를 지불해야 하기 때문에 중계하는 양쪽 체인의 충분한 잔액이 있는 계정에 접근할 수 있어야만 합니다. Relayer는 이 수수료를 회수하기 위해서 어플리케이션 레벨의 메소드을 사용할 수도 있습니다. 예로, 패킷 데이터0에 relayer 스스로를 위한 작은 양의 지불을 포함할 수 있습니다. Relayer의 수수료 지불에 대한 프로토콜은 해당 ICS의 미래 버전이나 별개의 ICS에서 설명할 것입니다. |
There was a problem hiding this comment.
Suggested change
| Relay 프로세스는 트랜잭션 수수료를 지불해야 하기 때문에 중계하는 양쪽 체인의 충분한 잔액이 있는 계정에 접근할 수 있어야만 합니다. Relayer는 이 수수료를 회수하기 위해서 어플리케이션 레벨의 메소드을 사용할 수도 있습니다. 예로, 패킷 데이터0에 relayer 스스로를 위한 작은 양의 지불을 포함할 수 있습니다. Relayer의 수수료 지불에 대한 프로토콜은 해당 ICS의 미래 버전이나 별개의 ICS에서 설명할 것입니다. | |
| Relay 프로세스는 트랜잭션 수수료를 지불해야 하기 때문에 중계하는 양쪽 체인의 충분한 잔액이 있는 계정에 접근할 수 있어야만 합니다. Relayer는 패킷 데이터에 작은 양의 지불을 포함하는 것과 같이 수수료를 회수하기 위한 어플리케이션 레벨의 메소드을 사용할 수도 있습니다. Relayer의 수수료 지불에 대한 프로토콜은 해당 ICS의 미래 버전이나 별개의 ICS에서 설명할 것입니다. |
junbeomlee
force-pushed
the
ics018-spec-relayer
branch
from
a475295
to
35c8cec
Compare
|
@hihiboss 반영완료! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.