Node syncing

[byeongsu-hong]

sync가 필요한 부분 (contract <-> localdb)

• collection registry
• schema registry
• app registry

생각해봐야할 점은

• sync가 꼭 필요한가?
• sync가 필요한 서비스들과 필요하지 않은 서비스를 분리
• 전용 프로토콜을 개발...?
  • 풀노드와 연결해서 모든 블록을 조사한 다음 이벤트를 필터링하는 작업은 매우 느릴 뿐만 아니라 풀노드를 운영하는 주체에게도 많은 부담을 안긴다.
  • 그렇다면 p2p protocol로 localdb를 공유하는건 어떨까?
  • 이렇게 되면 localdb에 저장되는 event정보는 그 event가 어떤 블록에 속해있는지, 그리고 그것을 검증할 수 있는 proof이 추가되게 됨.

[byeongsu-hong]

사실 지금은 생각하지 않아도 되지만, 추후에 필요할것이라고 생각함.

[therne]

Sync는 정확히는 인덱스 / 캐시 구축입니다. 가장 필요한곳은 Re-Encryption Key Retrieval (KeyManager)고 나머지는 캐시수준이라 큰 필요는 없을듯?

LocalDB는 캐시 및 국소적 인덱스기때문에 LocalDB를 공유하는건 좋은 디자인은 아닐수도 있습니다.

[byeongsu-hong]

캐시 수준이지만 registry가 생긴 후 많은 기간이 지났을 경우를 생각해본다면 필요할 수도 있습니다.
풀노드를 함께 돌리는 구조라면 상관이 없지만 특정 gateway를 유료로 사용하고 있는 노드라면 5000~1000단위의 블록을 하나하나 다 스캔한다는 것은 비용적으로 문제가 되겠죠.

[therne]

캐시는 서버 / 사용자마다 히트율이나 TTL이 전부 다르기 때문에 공유하더라도 이점이 없어요. 또한 Key-Value 형태의 캐시의 경우 온디맨드로 필요할때마다 구축하는게 더 빠르고요.

그럼에도 불구하고 풀블록을 스캔해서 캐시를 구축해야 하는 컴포넌트가 있나요? 있다면 블록데이터처럼 공유하는게 가능할것같은데

[byeongsu-hong]

일단 mapping으로 id => struct의 형식으로 관리되는 모든 컴포넌트들은 캐시가 필요하겠죠, ethereum에서는 그 관리되는 struct의 내부를 query할 수 없습니다. 예를 들어 특정 app에 속한 모든 collection을 찾고자 한다면 일단 collection registry에 있는 모든 collection들을 받아서 그 appId가 있는지 확인을 해야겠죠.
이런 상황에서 많은 낭비가 발생하므로 외부 저장소에 mapping에 대한 정보들을 저장하는것이 맞다고 생각했습니다.