From 6babc6658cd5ec3dda6a8f5874810a589acdfc6c Mon Sep 17 00:00:00 2001 From: diane Date: Sat, 11 Jan 2020 05:16:40 +0000 Subject: [PATCH] Translate 6_IBC_FAQ.md via GitLocalize --- ko/ibc/6_IBC_FAQ.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 ko/ibc/6_IBC_FAQ.md diff --git a/ko/ibc/6_IBC_FAQ.md b/ko/ibc/6_IBC_FAQ.md new file mode 100644 index 000000000..58f030e21 --- /dev/null +++ b/ko/ibc/6_IBC_FAQ.md @@ -0,0 +1,19 @@ +# 6: IBC Frequently-Asked Questions + +**IBC 프로토콜에 대해 자주 물어보는 질문을 답과 함께 정리한 문서입니다.** + +## Forks & unbonding periods + +*만약 체인에 분기가 발생하면, 만들어진 IBC 채널에는 무슨 일이 발생합니까?* + +이 상황은 light client 알고리즘에 따라 다릅니다. 텐더민트의 light client는 (equivocation처럼 보이기 때문에) 분기를 알게 되면 분기가 어떤 종류의 replay 보호 기능이 없다면(예, 체인 ID 변경) 채널을 완전히 정지시킵니다. 만약 하나의 분기가 체인 ID를 유지하고 다른 분기가 새로운 ID를 선택했다면, light client는 체인 ID를 유지한 분기를 따릅니다. 만약 두 분기 모두가 체인 ID(또는 검증자 집단)를 변경하면, 두 분기 모두 새로운 light client가 필요합니다. + +*채널을 연장하기 위해 IBC 패킷 없이 체인간 연결이 없는 시기가 지나면 무슨 일이 발생합니까? 묶여 있는 토큰은 개입 없이 복구할 수 있습니까?* + +기본적으로, 토큰은 복구할 수 없습니다. 거버넌스는 채널과 관련된 light client를 변경하려 개입할 수 있습니다 (이에 대한 자동화된 안전한 방법은 없습니다). 즉, 다른 검증 규칙을 사용하여 light client를 구성하거나, 이전에 유효했고 사용했던 경우 그리고 연결 해제 기간으로 인해 중지된 경우, 거버넌스에 제안하여 신뢰할 수 있는 header를 light client로 재설정하는 기능을 추가하는 것은 가능합니다. + +## Data flow & packet relay + +*블록체인 A가 블록체인 B에 IBC 패킷을 보내려면, 블록체인 B의 신뢰할 수 있는 노드의 주소를 알아야 합니까?* + +블록체인 A는 일종의 handshake가 발생한 후에 블록체인 B의 존재를 알게 됩니다. 이 handshake는 relayer가 가능하게 합니다. handshake를 시작할 때 해당 블록체인의 사용 가능한 노드에 접근하는 것은 relayer의 책임입니다. 블록체인 자체는 노드에 대해 알 필요가 없으며, 단지 노드 사이에 전달된 트랜잭션에 접근할 수 있습니다.