docs: translate ko/spec/ics-024-host-requirements/README.md#25
docs: translate ko/spec/ics-024-host-requirements/README.md#25junbeomlee wants to merge 1 commit intomasterfrom
Conversation
| - 단일 모듈은 여러 포트에 바인딩 할 수 있습니다 | ||
| - 포트는 선착순으로 할당되며 상태 머신이 처음 시작될 때 알려진 모듈에 대한 "예약된" 포트를 바인딩 할 수 있습니다 | ||
|
|
||
| 이 권한은 각 포트 (Cosmos SDK) 또는 소스 인증 (la Ethereum) 또는 호스트 상태 시스템에 의해 시행되는 다른 액세스 제어 방법을 통해 고유 한 참조 (객체 기능)로 구현할 수 있습니다. . 자세한 내용은 [ICS 5](../ics-005-port-allocation) 를 참조하십시오. |
There was a problem hiding this comment.
| 이 권한은 각 포트 (Cosmos SDK) 또는 소스 인증 (la Ethereum) 또는 호스트 상태 시스템에 의해 시행되는 다른 액세스 제어 방법을 통해 고유 한 참조 (객체 기능)로 구현할 수 있습니다. . 자세한 내용은 [ICS 5](../ics-005-port-allocation) 를 참조하십시오. | |
| 이 권한은 (코스모스 SDK 방식의) 각 포트 또는 (이더리움 방식의) 소스 인증 또는 호스트 상태 시스템에 의해 시행되는 다른 액세스 제어 방법을 통해 고유 한 참조 (객체 기능)로 구현할 수 있습니다. . 자세한 내용은 [ICS 5](../ics-005-port-allocation) 를 참조하십시오. |
a la ~는 뒤에 따라붙는 명사와 같은 방식(스타일)을 뜻한다고 합니다.
hihiboss
left a comment
There was a problem hiding this comment.
Commitment path introspection(183줄)까지 리뷰
|
|
||
| 이 표준 문서는 블록체인간 통신 프로토콜 구현체를 호스팅하는 상태머신이 반드시 제공하는 최소한의 인터페이스들과 반드시 충족되어야하는 속성들의 묶음을 정의합니다. | ||
|
|
||
| ### 동기(Motivation) |
There was a problem hiding this comment.
| ### 동기(Motivation) | |
| ### 의도 |
|
|
||
| ### 정의 | ||
|
|
||
| ### 요구 속성 |
There was a problem hiding this comment.
| ### 요구 속성 | |
| ### 지향 속성 |
|
|
||
| ### 모듈 시스템 | ||
|
|
||
| 호스트 상태 머신은 반드시 모듈 시스템을 지원해야 합니다. 이를 통해 상호 신뢰할 수 없는 코드 패키지가 동일한 원장에서 독립적이고, 잠재적으로 안전하게 실행될 수 있습니다. 또한 다른 모듈과 통신 할 수 있는 방법과 시기를 제어하고, "마스터 모듈" 또는 실행 환경에 의해 식별 및 조작 되어야 합니다. |
There was a problem hiding this comment.
| 호스트 상태 머신은 반드시 모듈 시스템을 지원해야 합니다. 이를 통해 상호 신뢰할 수 없는 코드 패키지가 동일한 원장에서 독립적이고, 잠재적으로 안전하게 실행될 수 있습니다. 또한 다른 모듈과 통신 할 수 있는 방법과 시기를 제어하고, "마스터 모듈" 또는 실행 환경에 의해 식별 및 조작 되어야 합니다. | |
| 호스트 상태 머신은 반드시 모듈 시스템을 지원해야 합니다. 이를 통해 상호 신뢰할 수 없는 코드 패키지가 동일한 원장에서 독립적이고, 잠재적으로 안전하게 실행될 수 있습니다. 또한 다른 모듈과 통신 할 수 있는 방법과 시기를 제어할 수 있고, "마스터 모듈" 또는 실행 환경에 의해 식별 및 조작될 수 있습니다. |
|
|
||
| `경로` 는 상태에 저장된 객체의 키로 사용되는 바이트 문자열입니다. 경로는 식별자, 상수 영숫자 문자열 및 구분자 `"/"` 만 포함해야 합니다. | ||
|
|
||
| 식별자는 가치있는 자원으로 의도된 것이 아니며 name squatting을 방지하기위해, 최소 길이 요구 사항 또는 의사 난수 생성이 구현 될 수 있지만 해당 사양에 대해 특정 제한이 적용되지 않습니다. |
There was a problem hiding this comment.
| 식별자는 가치있는 자원으로 의도된 것이 아니며 name squatting을 방지하기위해, 최소 길이 요구 사항 또는 의사 난수 생성이 구현 될 수 있지만 해당 사양에 대해 특정 제한이 적용되지 않습니다. | |
| 식별자는 가치있는 자원으로 의도된 것이 아니며 이름 중복을 방지하기위해, 최소 길이 요구 사항 또는 의사 난수 생성이 구현 될 수 있지만 해당 사양에 대해 특정 제한이 적용되지 않습니다. |
squat 가 '불법점거하다'라는 뜻이 있네요 :)
There was a problem hiding this comment.
dns 미리 선점하는것처럼 하는거라 중복은 아니지 않음?!!
There was a problem hiding this comment.
음 애매하긴 하네요. 저는 선점 당한다는것 자체를 중복으로 봐서... 괜히 오역하느니 영어 그대로 가져가는 것도 방법일듯..
| type delete = (path: Path) => void | ||
| ``` | ||
|
|
||
| `Path`는 위에서 정의한 대로 입니다. `Value`는 특정 데이터 구조를 인코딩한 임의의 바이트 문자열 입니다. 인코딩 세부 사항은 ICS를 분리하기 위해 남겨집니다. |
There was a problem hiding this comment.
| `Path`는 위에서 정의한 대로 입니다. `Value`는 특정 데이터 구조를 인코딩한 임의의 바이트 문자열 입니다. 인코딩 세부 사항은 ICS를 분리하기 위해 남겨집니다. | |
| `Path`는 위에서 정의한 대로 입니다. `Value`는 특정 데이터 구조를 인코딩한 임의의 바이트 문자열 입니다. 인코딩 세부 사항은 다른 ICS에서 다룹니다. |
| - 외부 증명을 지원할 수도 있지만 반드시 필요한 것은 아닙니다. IBC 핸들러는 증명해야 할 데이터를 절대로 기록하지 않습니다. | ||
| - 표준 proto3 데이터 구조를 사용할 수도 있지만 반드시 필요한 것은 아닙니다. 응용 프로그램 환경에서 선호하는 형식을 사용할 수 있습니다. | ||
|
|
||
| > 참고 : 이러한 방법과 속성을 제공하는 어떠한 키/값 저장소 인터페이스도 IBC에 사용되기에 충분합니다. 호스트 상태 머신은 경로 및 값 쌍 묶음과 직접적으로 일치하지 않는 경로 및 값 매핑으로 "프록시 저장소"를 구현할 수 있습니다. 또, 저장소 인터페이스를 통해 복구됩니다. - 경로는 단일 commitment에서 증명될 수 있는 페이지에 저장된 버킷 및 값으로 그룹화 될 수 있습니다. 경로는 일대일 대응으로 비연속적이게 재맵핑될 수 있습니다. - `get` , `set` 및 `delete` 가 예상대로 동작하고 다른 기계가 provable 저장소의 경로 및 값 쌍의 commitment 증명 (또는 그 부재)을 검증할 수 있습니다. 적용가능한 경우, 저장소는 이 맵핑을 외부에 노출하여 (중계자를 포함한) 클라이언트가 저장소 레이아웃과 증명 구성 방법을 결정할 수 있어야 합니다. 이러한 프록시 저장소를 사용하는 기계의 클라이언트는 또한 뱁핑을 이해하여, 새로운 클라이언트 유형 또는 매개 변수화된 클라이언트를 요구할 수 있습니다. |
There was a problem hiding this comment.
| > 참고 : 이러한 방법과 속성을 제공하는 어떠한 키/값 저장소 인터페이스도 IBC에 사용되기에 충분합니다. 호스트 상태 머신은 경로 및 값 쌍 묶음과 직접적으로 일치하지 않는 경로 및 값 매핑으로 "프록시 저장소"를 구현할 수 있습니다. 또, 저장소 인터페이스를 통해 복구됩니다. - 경로는 단일 commitment에서 증명될 수 있는 페이지에 저장된 버킷 및 값으로 그룹화 될 수 있습니다. 경로는 일대일 대응으로 비연속적이게 재맵핑될 수 있습니다. - `get` , `set` 및 `delete` 가 예상대로 동작하고 다른 기계가 provable 저장소의 경로 및 값 쌍의 commitment 증명 (또는 그 부재)을 검증할 수 있습니다. 적용가능한 경우, 저장소는 이 맵핑을 외부에 노출하여 (중계자를 포함한) 클라이언트가 저장소 레이아웃과 증명 구성 방법을 결정할 수 있어야 합니다. 이러한 프록시 저장소를 사용하는 기계의 클라이언트는 또한 뱁핑을 이해하여, 새로운 클라이언트 유형 또는 매개 변수화된 클라이언트를 요구할 수 있습니다. | |
| > 참고 : 이러한 방법과 속성을 제공하는 어떠한 키/값 저장소 인터페이스도 IBC에 사용되기에 충분합니다. 호스트 상태 머신은 경로 및 값 쌍 묶음과 직접적으로 일치하지 않는 경로 및 값 매핑으로 "프록시 저장소"를 구현할 수 있습니다. 또, `get` , `set` 및 `delete` 가 예상대로 동작하는 한 저장소 인터페이스를 통해 복구할 수 있습니다. - 경로는 단일 commitment에서 증명될 수 있는 페이지에 저장된 버킷 및 값으로 그룹화 될 수 있습니다. 경로는 일대일 대응으로 비연속적이게 재맵핑될 수 있습니다. - 그리고 다른 기계가 provable 저장소의 경로 및 값 쌍의 commitment 증명 (또는 그 부재)을 검증할 수 있습니다. 적용가능한 경우, 저장소는 이 맵핑을 외부에 노출하여 (중계자를 포함한) 클라이언트가 저장소 레이아웃과 증명 구성 방법을 결정할 수 있어야 합니다. 이러한 프록시 저장소를 사용하는 기계의 클라이언트는 또한 맵핑을 이해하여, 새로운 클라이언트 유형 또는 매개 변수화된 클라이언트를 요구할 수 있습니다. |
| type getConsensusState = (height: uint64) => ConsensusState | ||
| ``` | ||
|
|
||
| `getConsensusState` 는 적어도 `n` 개의 연속된 최근 높이에 대한 합의 상태를 반환해야 합니다. 여기서 `n` 은 호스트 상태 시스템에 대해 일정합니다. `n` 보다 오래된 높이는 안전하게 정리할 수 있습니다(이러한 키로 인해 향후 호출이 실패할 수 있음). |
There was a problem hiding this comment.
| `getConsensusState` 는 적어도 `n` 개의 연속된 최근 높이에 대한 합의 상태를 반환해야 합니다. 여기서 `n` 은 호스트 상태 시스템에 대해 일정합니다. `n` 보다 오래된 높이는 안전하게 정리할 수 있습니다(이러한 키로 인해 향후 호출이 실패할 수 있음). | |
| `getConsensusState` 는 적어도 `n` 개의 연속된 최근 높이에 대한 합의 상태를 반환해야 합니다. 여기서 `n` 은 호스트 상태 시스템에 대해 일정합니다. `n` 보다 오래된 높이는 안전하게 정리할 수 있습니다(이러한 높이로 인해 향후 호출을 실패시킬 수 있음). |
|
|
||
| `getConsensusState` 는 적어도 `n` 개의 연속된 최근 높이에 대한 합의 상태를 반환해야 합니다. 여기서 `n` 은 호스트 상태 시스템에 대해 일정합니다. `n` 보다 오래된 높이는 안전하게 정리할 수 있습니다(이러한 키로 인해 향후 호출이 실패할 수 있음). | ||
|
|
||
| 호스트 상태 머신은 `getStoredRecentConsensusStateCount` 하여 저장된 최근 컨센서스 상태 카운트 `n`을 조회 할 수 있는 기능을 제공해야합니다. |
There was a problem hiding this comment.
| 호스트 상태 머신은 `getStoredRecentConsensusStateCount` 하여 저장된 최근 컨센서스 상태 카운트 `n`을 조회 할 수 있는 기능을 제공해야합니다. | |
| 호스트 상태 머신은 `getStoredRecentConsensusStateCount`를 통하여 저장된 최근 컨센서스 상태 카운트 `n`을 조회 할 수 있는 기능을 제공해야합니다. |
|
@hihiboss @gurrpi 반영완료! |
|
|
||
| `경로` 는 상태에 저장된 객체의 키로 사용되는 바이트 문자열입니다. 경로는 식별자, 상수 영숫자 문자열 및 구분자 `"/"` 만 포함해야 합니다. | ||
|
|
||
| 식별자는 가치있는 자원으로 의도된 것이 아니며 name squatting을 방지하기위해, 최소 길이 요구 사항 또는 의사 난수 생성이 구현 될 수 있지만 해당 사양에 대해 특정 제한이 적용되지 않습니다. |
There was a problem hiding this comment.
음 애매하긴 하네요. 저는 선점 당한다는것 자체를 중복으로 봐서... 괜히 오역하느니 영어 그대로 가져가는 것도 방법일듯..
|
|
||
| ### Port system | ||
|
|
||
| 호스트 상태 머신은 반드시 포트 시스템을 구현해야하며, 여기서 IBC 핸들러는 호스트 상태 머신의 다른 모듈이 고유하게 명명 된 포트에 바인딩 할 수 있도록합니다. 포트는 식별자로 `Identifier` 됩니다. |
There was a problem hiding this comment.
| 호스트 상태 머신은 반드시 포트 시스템을 구현해야하며, 여기서 IBC 핸들러는 호스트 상태 머신의 다른 모듈이 고유하게 명명 된 포트에 바인딩 할 수 있도록합니다. 포트는 식별자로 `Identifier` 됩니다. | |
| 호스트 상태 머신은 반드시 포트 시스템을 구현해야하며, 여기서 IBC 핸들러는 호스트 상태 머신의 다른 모듈이 고유한 이름의 포트에 할당될 수 있도록 합니다. 포트는 `Identifier`로 식별됩니다. |
| - 단일 모듈은 여러 포트에 바인딩 할 수 있습니다 | ||
| - 포트는 선착순으로 할당되며 상태 머신이 처음 시작될 때 알려진 모듈에 대한 "예약된" 포트를 바인딩 할 수 있습니다 | ||
|
|
||
| 이 권한은 (코스모스 SDK 방식의) 각 포트 또는 (이더리움 방식의) 소스 인증 또는 호스트 상태 시스템에 의해 시행되는 다른 액세스 제어 방법을 통해 고유 한 참조 (객체 기능)로 구현할 수 있습니다. 자세한 내용은 [ICS 5](../ics-005-port-allocation) 를 참조하십시오. |
There was a problem hiding this comment.
| 이 권한은 (코스모스 SDK 방식의) 각 포트 또는 (이더리움 방식의) 소스 인증 또는 호스트 상태 시스템에 의해 시행되는 다른 액세스 제어 방법을 통해 고유 한 참조 (객체 기능)로 구현할 수 있습니다. 자세한 내용은 [ICS 5](../ics-005-port-allocation) 를 참조하십시오. | |
| 이 권한은 (코스모스 SDK 방식의) 각 포트에 대한 고유한 참조(객체 기능) 또는 호스트 상태 머신에 의해 시행되는 다른 접근 제어 방법으로 구현할 수 있습니다. 자세한 내용은 [ICS 5](../ics-005-port-allocation) 를 참조하십시오. |
| type submitDatagram = (datagram: Datagram) => void | ||
| ``` | ||
|
|
||
| `submitDatagram`을 사용하면 relayer process가 IBC 데이터 그램을 호스트 상태 머신의 라우팅 모듈에 직접 제출할 수 있습니다. 호스트 상태 머신은 데이터 그램을 제출하는 relayer process가 거래 수수료를 지불하고 더 큰 트랜잭션 구조에서 데이터 그램에 서명하는 계정을 가지고 있어야 합니다. `submitDatagram`은 필요한 패키징을 정의하고 구성해야 합니다. |
There was a problem hiding this comment.
| `submitDatagram`을 사용하면 relayer process가 IBC 데이터 그램을 호스트 상태 머신의 라우팅 모듈에 직접 제출할 수 있습니다. 호스트 상태 머신은 데이터 그램을 제출하는 relayer process가 거래 수수료를 지불하고 더 큰 트랜잭션 구조에서 데이터 그램에 서명하는 계정을 가지고 있어야 합니다. `submitDatagram`은 필요한 패키징을 정의하고 구성해야 합니다. | |
| `submitDatagram`을 사용하면 relayer process가 IBC 데이터 그램을 호스트 상태 머신의 라우팅 모듈에 직접 제출할 수 있습니다. 호스트 상태 머신은 데이터 그램을 제출하는 relayer process가 거래 수수료를 지불할 계정을 가지고 더 큰 트랜잭션 구조의 데이터그램에 서명할 수 있도록 할 수 있습니다. `submitDatagram`은 필요한 패키징을 정의하고 구성해야 합니다. |
|
|
||
| 호스트 상태 머신은 예외 시스템을 지원해야하며, 이를 통해 트랜잭션은 실행을 중단할 수 있고 이전에 수행 한 상태 변경 (같은 트랜잭션 내에서 발생하는 다른 모듈의 상태 변경 포함 및 적절한 가스 소비 및 수수료 지불 포함)을 되돌릴 수 있습니다. 그리고 시스템 불변 위반은 상태 머신을 정지시킬 수 있습니다. | ||
|
|
||
| 이 예외 시스템은 `abortTransactionUnless` 및 `abortSystemUnless` 두 함수를 통해 노출되어야 합니다. 전자는 트랜잭션을 revert 시키며 후자는 상태 머신을 정지시킵니다. |
There was a problem hiding this comment.
| 이 예외 시스템은 `abortTransactionUnless` 및 `abortSystemUnless` 두 함수를 통해 노출되어야 합니다. 전자는 트랜잭션을 revert 시키며 후자는 상태 머신을 정지시킵니다. | |
| 이 예외 시스템은 `abortTransactionUnless` 및 `abortSystemUnless` 두 함수를 통해 노출되어야 합니다. 전자는 트랜잭션을 되돌리며 후자는 상태 머신을 정지시킵니다. |
| type abortTransactionUnless = (bool) => void | ||
| ``` | ||
|
|
||
| `abortTransactionUnless`로 전달 된 bool 값이 `true`인 경우 호스트 상태 시스템은 아무 작업도 수행 할 필요가 없습니다. `abortTransactionUnless` 로 전달 된 bool 값이 `false`인 경우 호스트 상태 머신은 트랜잭션을 중단하고 가스 소비 및 수수료 지불을 제외하고 이전에 변경 한 상태 변경을 되돌려 야합니다. |
There was a problem hiding this comment.
| `abortTransactionUnless`로 전달 된 bool 값이 `true`인 경우 호스트 상태 시스템은 아무 작업도 수행 할 필요가 없습니다. `abortTransactionUnless` 로 전달 된 bool 값이 `false`인 경우 호스트 상태 머신은 트랜잭션을 중단하고 가스 소비 및 수수료 지불을 제외하고 이전에 변경 한 상태 변경을 되돌려 야합니다. | |
| `abortTransactionUnless`로 전달 된 bool 값이 `true`인 경우 호스트 상태 시스템은 아무 작업도 수행 할 필요가 없습니다. `abortTransactionUnless` 로 전달 된 bool 값이 `false`인 경우 호스트 상태 머신은 소비한 가스 및 수수료 지불값을 제외하고 트랜잭션을 중단해야하며 이전의 상태 변경을 되돌려야 합니다. |
|
|
||
| delivery-or-timeout safety를 위해 호스트 상태 머신은 최종 데이터 가용성을 가져야하며, 상태의 모든 key/value 쌍을 결국 relayer에 의해 검색 할 수 있습니다. exactly-once safety를 위해 데이터 가용성이 필요하지 않습니다. | ||
|
|
||
| 패킷 relay의 liveness을 위해 호스트 상태 머신은 transactional liveness을 제한해야하며 (따라서 반드시 consensus liveness를 가져야합니다.), 따라서 들어오는 트랜잭션은 블록 높이 제한 내에서 (특히, 패킷에 할당 된 시간 초과보다 작음) 반드시 confirm 됩니다. |
There was a problem hiding this comment.
| 패킷 relay의 liveness을 위해 호스트 상태 머신은 transactional liveness을 제한해야하며 (따라서 반드시 consensus liveness를 가져야합니다.), 따라서 들어오는 트랜잭션은 블록 높이 제한 내에서 (특히, 패킷에 할당 된 시간 초과보다 작음) 반드시 confirm 됩니다. | |
| 패킷 relay의 liveness을 위해 호스트 상태 머신은 transactional liveness을 제한해야하며 (그러므로 반드시 consensus liveness를 가져야 함), 따라서 들어오는 트랜잭션은 블록 높이 제한 내에서 (특히, 패킷에 할당 된 시간 초과보다 작음) 확정됩니다. |
|
|
||
| ### 이벤트 로깅 시스템 | ||
|
|
||
| 호스트 상태 머신은 반드시 이벤트 로깅 시스템을 제공해야 합니다. 이벤트 로깅 시스템에서는 트랜잭션 실행 과정에서 임의의 데이터들이 로깅되며, 로깅되는 데이터들은 상태 머신을 실행하는 프로세스에 의해 저장, 인덱싱 및 나중에 조회 할 수 있어야 합니다. 이러한 이벤트 로그는 relayer에서 IBC 패킷 데이터 및 시간 초과를 읽는 데 사용되며, 이 로그는 체인의 State에 직접 저장되지 않지만 (State 저장소는 비용이 많이 드는 것으로 추정 됨) 간결한 cryptographic commitment로 커밋됩니다(commitment 만 저장 됨). |
There was a problem hiding this comment.
| 호스트 상태 머신은 반드시 이벤트 로깅 시스템을 제공해야 합니다. 이벤트 로깅 시스템에서는 트랜잭션 실행 과정에서 임의의 데이터들이 로깅되며, 로깅되는 데이터들은 상태 머신을 실행하는 프로세스에 의해 저장, 인덱싱 및 나중에 조회 할 수 있어야 합니다. 이러한 이벤트 로그는 relayer에서 IBC 패킷 데이터 및 시간 초과를 읽는 데 사용되며, 이 로그는 체인의 State에 직접 저장되지 않지만 (State 저장소는 비용이 많이 드는 것으로 추정 됨) 간결한 cryptographic commitment로 커밋됩니다(commitment 만 저장 됨). | |
| 호스트 상태 머신은 반드시 이벤트 로깅 시스템을 제공해야 합니다. 이벤트 로깅 시스템에서는 트랜잭션 실행 과정에서 임의의 데이터들이 로깅되며, 로깅되는 데이터들은 상태 머신을 실행하는 프로세스에 의해 저장, 인덱싱 및 나중에 조회 할 수 있어야 합니다. 이러한 이벤트 로그는 relayer에서 IBC 패킷 데이터 및 시간 초과를 읽는 데 사용되며, 이 로그는 체인의 State에 직접 저장되지 않지만 (State 저장소는 비용이 많이 들기 때문에) 간결한 cryptographic commitment로 커밋됩니다(commitment 만 저장 됨). |
No description provided.