hi @Antismart , welcome to the community! I see Neon is surveying about indexing requirements as well. I added this comment on Github but I noticed the post here and figured this is a better place for conversation.
The question about RPC’s with CKB is a long-standing one, and grateful to see you stepping into the fold to find how to make CKB more accessible to developers (and ones that would like to avoid running infrastructure themselves)
Here’s the comment from Github, I’m sure there will be plenty of ideas around RPC shared on this post, appreciate your interest.
——————————————–
Really appreciate the work you are doing on this, it does seem like an important piece for many people who are coming into the ecosystem, and the current public RPC’s were never intended to be used for anything more than testing.
I want to highlight an important thing about RPCs:
given the recent $300m hack in the Ethereum ecosystem originating from compromised RPCs, integrity of data from the RPC could be considered as part of the feature set as well.
Any cell data can be proven through previous transaction inclusion, which can be proven through Merkle branches up to a block header, which can be proven up through Merkle branches to the Block MMR field in the extension block of a recent block header.
Through Flyclient, the client can verify that this is all from a recent block in the chain tip.
I know this may seem overly burdensome at this stage, however if these things were considered a decade ago in the Ethereum community and others, the $300m hack would have never happened. It seems like more of an architectural consideration across the ecosystem right now, rather than things that should be required for implementations, this is why I mention it.
There is a downstream consideration of the client verifying what it is signing as well.
I can see this property where “like likes like” , in that insecure paradigms will lead to more insecurity, whereas secure paradigms will lead to more security, simply because it feels strange (or at least worthy of inquiry) to create a insecure thing downstream from a secure thing, while creating a further insecure thing downstream from an insecure thing seems perfectly pragmatic.