question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[proposal] fetch ERC1056 events till a specific block

See original GitHub issue

Is your feature request related to a problem? Please describe. No

Describe the solution you’d like Reading / Caching of ERC1056 events should be possible from the latest block to some older block. For a cache based use-case, the solution would already store the events from the ERC1056 contracts. Whenever a user requests a DID-Doc, the resolver should sync / fetch events from the last synced block to latest block.

This makes the changeLog to have a property something like stopBlockNumber. While executing wrapDidDocument the changeLog could then possibly pull events between the latest block and specified stopBlockNumber. Thus if there is no specified stopBlockNumber, then it pull all the events from the blockchain.

Describe alternatives you’ve considered NA

Additional context NA

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:14 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
mirceaniscommented, Mar 16, 2022

Yes, that’s the idea. The resolver would not care that the provider is caching events or not.

1reaction
nichoniencommented, Mar 10, 2022

The whole point of DIDs is to not require trust between organizations and their users I completely agree with you on this and have quoted it earlier as well I agree with you, the resolver should build the cache internally in order to make it more transparent and trustful.

The two main reason for having “external” cache are :

  1. The caching could be a possible requirement for certain use-case or businesses, so I see it as an option.
  2. If did:ethr resolver has internal caching, organisations would be bound to manage different cache for different purposes.

You understood the proposal right, we are just brainstorming for an optimal approach.

Read more comments on GitHub >

github_iconTop Results From Across the Web

lacchain-did-registry/DID_SPEC.md at master
We propose a new DID method based on ERC-1056 and is intended to use Ethereum addresses as fully self-managed Decentralized Identifiers ...
Read more >
EIP-1056: Ethereum Lightweight Identity
Efficient lookup of events through linked identity events · Lookup previousChange block for identity · Lookup all events for given identity ...
Read more >
The Basics of Decentralized Identity | by Kames | uPort
We take a simple concept of privately signing information using cryptographic primitives and have built a relatively mature data sharing protocol, that reaches ......
Read more >
Ethereum ERC Standards You Should Know About
A major limitation of the ERC20 token standard is the lack of a way to 'react' to ERC20 transfer events. This results in...
Read more >
Decentralized Identity and Access Management Framework ...
However, IoT devices tend to offer particular and diverse data and ... A public blockchain identity platform is supported by Ethereum using ERC1056...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found