안녕하세요 고생하십니다.
현재 Dapp을 만들어 배포를하고 성능테스트를 진행하고 있습니다.
별도의 엔드포인트 노드를 통해 클레이튼과 상호작용 중 입니다.
그런데 가끔 (꽤나 자주…) 하나의 블록에 1000개 이상의 트랜젝션이 몰리는 경우가 있습니다.
추측컨데 klayswap 등의 DeFi 서비스에서 수많은 토큰 스왑이 일어나는 것 같습니다.
이 때는 elapsed time이 1000ms 이상이 나오기도 합니다.
노드의 부하 시기와 DApp에서 트랜잭션을 보내는 시기가 겹치면 mempool에서 dapp의 트랜잭션이 뒤 늦게 채택되는 건지 부하가 종료되고 dapp의 트랜잭션이 블록에 쓰여집니다.
저의 DApp에서는 특정 블록에 트랜잭션을 담아야 하는 시나리오가 존재합니다.
만일 DeFi들의 스왑 등으로 부하가 심한 시기와 DApp이 트랜잭션을 날려야하는 블록 넘버가 겹치는 경우에는 정상 작동을 하지 않을텐데, 이럴 경우 노드 스펙 증설로 해결이 가능할까요?
현재 저의 en node의 스펙은 다음과 같습니다.
CPU: 12 core / 20 thread
Memory: 64GB
Storage: 4T SSD
노드 스펙이 충분하다면 kend의 최적화 방안 혹은 os 파라미터 튜닝 등이 궁금합니다.
번외)
혹시 클레이튼 mempool에서 gas limit이 큰 순서대로 채굴을 하나요?
그렇다면 gas limit을 증가시키는 것도 솔루션 중 하나가 될 수 있을까요?
감사합니다.
안녕하세요. 클레이튼 포럼에 글을 남겨주셔서 감사합니다.
질문이 여러개 있어, 내용을 정리해서 한번에 답변하겠습니다.
Q1. 저의 DApp에서는 특정 블록에 트랜잭션을 담아야 하는 시나리오가 존재합니다. 노드 스펙 증설로 해결이 가능할까요?
A1. 블록체인에 특정 블록에 특정 트랜잭션이 담기도록 하는건 non deterministic 한 행위입니다. txpool에 블록에 들어가기를 대기하고 있는 transaction들을 pending transaction이라고 하는데, 클레이튼 메인넷이 이 pending transaction을 처리하는 속도 및 트랜잭션 개수 등 다양한 외부 요인에 영향을 받습니다. 결론적으로 노드 스펙이 높다 하더라도 이런 외부요인을 통제하거나 예측할수 있는게 아니기 때문에 말씀주신 로직은 설계대로 실현이 어려울 가능성이 있습니다.
Q2. 혹시 클레이튼 mempool에서 gas limit이 큰 순서대로 채굴을 하나요? 그렇다면 gas limit을 증가시키는 것도 솔루션 중 하나가 될 수 있을까요?
A2. 아니오. gasLimit은 단순히 트랜잭션을 실행하는데 있어서 사용될 가스량의 한계를 지정해 주는 것에 불과합니다. 클레이튼의 경우 GasPrice가 고정값이므로 gasfee 에 따라 블록체인에 기록되는 순서가 정해지는 것이 아닙니다.
Q3. 노드 스펙이 충분하다면 kend의 최적화 방안 혹은 os 파라미터 튜닝 등이 궁금합니다.
A3. En 운영 관련: 부하 상황 대비 해당 글에 EN 노드 운영 관련 여러 팁이 있으니 참고 바랍니다.
