안녕하세요 클레이튼 서비스체인을 구동할려고 하고 있는데요. . en 노드 하나와 scn 노드 4개를 돌리고 앵커링과 브릿지 기능을 구현하려고 하는게 목표입니다. 자료를 찾아보니 servicechain-deploy 깃헙 을 사용하면 쉽게 할 수 있다고 들어서 사용하려고 시도 중입니다. 그 과정 중에 생긴 질문들이 몇가지 있습니다.
en 노드를 Cypress 넷으로 돌려서 메인넷과 앵커링 하고 싶은데 servicechain-deploy 깃헙에서 servicechain-deploy/klaytn-terraform/service-chain-aws/deploy-4scn/en_node.tf 에 있는 ami 설정에서 filter 값만 cypress 것으로 변경하면 될까요?
앵커링과 브릿지 기능을 위해서 en 노드를 따로 제가 운영하지 않고 공용 엔드포인트 노드를 사용해서 앵커링을 할 수는 없나요?
run-en-4scn.sh 스크립트가 성공적으로 모두 실행 시에 앵커링과 브릿지 기능이 모두 잘 실행되는게 맞는지 여쭈고 싶습니다.
run-en-4scn.sh 돌렸을 때 elastic ip 제한에 걸렸다는 메시지가 떠서 서울 리전의 elastic ip 제한 증가를 aws 안내 센터에 요청 했는데 맞게 한건지 궁금합니다.
말씀하신대로 EN 노드의 AMI를 Cypress 것으로 사용하셔야 합니다. 또한 브리지 설정 시 parent chain ID를 필요로 하는데 Baobab과 Cypress의 chain ID가 상이(각각 1001, 8217)하기 때문에, 해당 설정 또한 변경해 주어야 합니다.
공용 엔드포인트 노드의 경우 브리지 설정을 하실 수 있는 권한이 없을 것으로 예상됩니다.
이해하신 것과 같이 klaytn-ansible 의 klaytn_bridge role에 브리지 및 앵커링 활성화 설정이 포함되어 있습니다. 앵커링의 경우 기본값이 활성화하도록 되어있고 앵커링 주기 기본값은 매 블록당 앵커링 하도록 되어있습니다. 해당 설정 파일
AWS쪽 에러이기 때문에 정확한 답변을 드리기 어려울 것 같습니다만, 저도 구글링 해본 결과 기본적으로 리전마다 5개까지의 EIP를 할당할 수 있고 더 많이 사용하고 싶으면 제한 증가를 해야하는 것 같네요. 제한 증가가 완료되면 다시 시도해 보시길 바랍니다.
servicechain-deploy에 관심 가져 주셔서 감사합니다. 답변에 이해되지 않는 부분이 있거나 더 궁금한 점이 있으시면 알려주세요.
일단 답변에 감사드립니다. 현재 eip 제한을 증가시켜서 인스턴스 생성과 노드 설치까지 완료했는데 그 뒷 부분에 추가적으로 질문이 있습니다.
run-en-4scn.sh 파일에서 /2.setup_nodes.sh 실행까지는 잘 완료된 것을 확인했습니다. 이후 en 노드의 동기화를 기다리는 코드에서 더 이상 진행 되지 않아서 확인해보니 아래 코드에서 반응이 없어서 멈췄더군요
EN_SYNCING=$(ssh -i ~/.ssh/servicechain-deploy-key ec2-user@$EN_IP “sudo ken attach /var/kend/data/klay.ipc --exec klay.syncing”)
그래서 제가 en 노드에 ssh 연결을 해서 해당 명령어를 쳐봤을 때 --exec 플래그와 상관없이 자바스크립트 콘솔로 진입하는 것을 확인했습니다. 아마 이것 때문에 막힌 것 같네요 그리고 자바스크립트 콘솔에서 klay.syncing 을 입력했을 때 아래와 같이 출력이 나왔습니다.
제가 en 노드를 돌린지 3시간이 넘은 상태에서 확인했고 동기화가 되지 않은 것 같은데 얼마나 기다려야 되는건지 궁금합니다. => (나중에 다시 한번 확인해보니 동기화된 것을 확인했습니다. 시간이 엄청 오래걸리네요)
제가 운영하는 서비스체인에 트랜잭션을 보낼 떄 rpc 는 scn 노드의 8551 포트를 사용하면 되는지 궁금합니다. 제가 ethers.js 를 사용해서 scn 8551 포트로 컨트랙트 배포 트랜잭션을 보냈을 때는 아래와 같이 에러가 발생했었습니다.
ProviderError: the method net_version does not exist/is not available
at HttpProvider.request (/home/xione/testSCN/node_modules/hardhat/src/internal/core/providers/http.ts:88:21)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at ChainIdValidatorProvider._getChainIdFromEthNetVersion (/home/xione/testSCN/node_modules/hardhat/src/internal/core/providers/chainId.ts:33:17)
at ChainIdValidatorProvider._getChainId (/home/xione/testSCN/node_modules/hardhat/src/internal/core/providers/chainId.ts:17:25)
at ChainIdValidatorProvider.request (/home/xione/testSCN/node_modules/hardhat/src/internal/core/providers/chainId.ts:55:29)
at EthersProviderWrapper.send (/home/xione/testSCN/node_modules/@nomiclabs/hardhat-ethers/src/internal/ethers-provider-wrapper.ts:13:20)
at getSigners (/home/xione/testSCN/node_modules/@nomiclabs/hardhat-ethers/src/internal/helpers.ts:45:20)
at getContractFactoryByAbiAndBytecode (/home/xione/testSCN/node_modules/@nomiclabs/hardhat-ethers/src/internal/helpers.ts:284:21)
at main (/home/xione/testSCN/scripts/deploy.js:9:17)
AMI가 하루에 한번씩 생성되기 때문에 최대 하루치 블록을 따라잡는데에 시간이 걸립니다. 이는 어쩔 수 없을 것 같습니다. 그리고 --exec 인자가 무시되는 이유는 최근 플래그 처리 라이브러리를 업그레이드하며 생기는 문제로 보이는데요, ken attach --exec klay.syncing /var/kend/data/klay.ipc 와 같이 넣어주어야 제대로 동작합니다. 이는 servicechain-deploy 코드가 클레이튼 노드의 최신 버전에 맞게 업데이트 되지 않아서 발생하는 문제입니다.
기본값으로 RPC port는 8551입니다. 해당 에러는 포트로 인한 에러가 아닌 “net” API 네임스페이스가 열려 있지 않아서 발생하는 에러인 것으로 보입니다. 기본값으로 RPC 네임스페이스는 "klay"와 "admin"이 열리게 되어 있습니다. (브리지 설정을 하는 경우 SCN은 "subbridge"도 열립니다, 링크) 따라서 SCN 설정 파일(kscnd.conf)에서 RPC_API 설정에 “net” 등 필요한 네임스페이스를 추가하고 노드를 재시작해야 할 것으로 보입니다.
에러 메시지에서 설명하듯 data 디렉토리에 klay.ipc 파일이 없기 때문입니다. --datadir 옵션에 노드 데이터 디렉토리 경로를 넣어주셔야 합니다. servicechain-deploy를 이용해서 설치하신 경우 /var/kscnd/data를 사용하시면 됩니다.
네, 1번과 같은 이유일 것 같네요.
servicechain-deploy가 제대로 유지보수되지 않아 발생하는 문제들이 많네요. 현재 servicechain-deploy의 유지보수 작업의 우선순위가 높지 않아 당장은 스크립트를 수정해서 사용하시는 것을 추천드립니다.
TPS는 HW 스펙에 따라 다를 것 같습니다. 메인넷의 경우 4000 TPS가 나온다고 알려져 있으나 HW 요구사항이 높고, CN/PN/EN으로 나뉘어져 있어 정확한 비교가 어렵겠네요. 메인넷과 동일한 수준의 HW를 갖춘다면 4000 TPS와 유사한 수치가 나올 것으로 예상합니다.
하드포크는 네트워크(체인) 전체에 적용되어야 하므로 모든 SCN이 해주어야 합니다.
계정을 지정할 수는 없고, 지금처럼 SCN에 대한 접근을 제한하는 방법을 사용하셔야 할 것 같습니다.
권장드리는 기준은 없습니다. 말씀하신대로 매 블록을 앵커링하면 높은 신뢰성을 제공할 수 있는 대신 비용이 늘어나고, 앵커링 주기를 늘리면 비용을 아낄 수 있는 대신 private network로서 높은 신뢰성을 제공하기 어려울 수 있습니다.
genesis.json를 수정하고 적용하려면 찾으신 문서에서 설명하듯이 init 명령어를 통해 genesis.json의 내용을 체인 데이터베이스에 업데이트 해주어야 하는데, 말씀하신 경우와 같이 기존에 있는 내용을 수정하는 경우 에러가 발생하게 됩니다. 대신 governance.vote() 기능을 이용해서 epoch를 줄이거나 체인을 새로 시작하는 방법이 있을 것 같습니다.