unpackdev / inspector Goto Github PK

Higher overview idea is to have instance, running badgerdb that contains all necessary and crutial information about contracts such as license, entry source name, source code of the contract, compiler version and so on.

Additional functionality is gprc interface to which we can connect and request new data or retrieve existing data.

Accessing and writing into badgerdb from multiple applications to same database instance is not possible due to consistencies and locks which are enforced via badgerdb itself... Therefore we don't have choice if we want to use badger and I really want to use it.

List of the contracts that we have issues parsing them. Those with [x] are fixed.

Ethereum

So far what I see there are groups of errors, mostly the same. Like 3-4 different type of errors that needs to be sorted out. These are contracts bellow, won't add all of them that represent type of an error.

• 0x8ad5505BfE38692630A51f1a47EDe66a8d2E8b13
• 0xC4BE5878ed62292283DED69d269F67B19B262d2c
• 0xB2289296D93a80B052B518890Ac1497d3dc35a44
• 0xF68FfFC8A2cD678562Fc73f13FDA8044e57fA574
• 0x1989413Eb640fA8B7beB2A04DDb8ad88a1ddA986
• 0x0CE833EE4d97CEDc22bBf3B85c04b1fd9Ac5AbDd

Proxy

Contracts that should be discovered as proxy (proxy impl addr) but is not...

• 0x8c81D0e16582e411c770A01DD0ADD23B9dF38bf9

It is not hard to build downloader as it's hard to maintain the shred amount of the data in the repository. It takes forever to clone and even git status within the project is slow due to million of indexes that it needs to maintain.

I need to find better way to handle this. It's not long term sane to have millions of files in this repository like it is now.

Basically source code may be missing or from the IPFS or from external sources at the time it's created. Which is quite expected. Therefore, somehow there should be a listeners/watchers that handle these things?

Or should it be left to the engineer requesting it and downloading in the real time? <- This is probably the best.

This is the list of future work for state package:

• Currently it writes new states as soon as it happens, which means, load on redis will be higher then probably we want. Perhaps to write every few seconds with post application shutdown sequence to write latest information.
• Sync package should be used to ensure concurrent writes and reads are handled correctly.

It can back up the queue and due to it, nats report slow consumer as it cannot really inject due to channel buffer being full. Adding this here for later on to sort it out.

In addition a way to catch errors (nats error handler) + a way to overwrite the default handler

Right now export is possible but import is not at least in meaning of running 1 command and that's it. Need to make this happen.

Perhaps it will be better to go with the clickhouse instead of Sqlite3. It can be quite slow, even if there are indexes. Need to do the research how we would:

a.) Store the data, map the data.
b.) Exporting and data importing.

Will be fixed on later on. Adding this ticket here so it's set to stone for fixing.