aergoio / aergoscan Goto Github PK

This is an Elasticsearch limitation. A workaround would be to use a Scroll.

This problem appears on table views with a lot of entries, e.g. https://testnet.aergoscan.io/transactions

Let users upload contract code and verify that the stored code matches.

Questions:

• Where to store code? So far, Aergoscan's only data storage is the indexer's elasticsearch

We now have a token factory contract. The code is here:

https://github.com/aergoio/ARC1-Extensions/tree/master/factory

Here is it deployed on alphanet:

https://aergoio.github.io/tx-builder/#/contract/Amgu52QrSVmLMJ8DMZnksNEgY164AaMKihCeowzVcmz6KQz5xXp2

We are able to create new tokens from this contract. But the created tokens are not recognized by aergoscan (on alphanet)

Here is an example token creation (transaction):

https://alpha.aergoscan.io/transaction/HaCKynPaMKMN4mWWxdqzVEPaJ3ySgeyEXkDJP3bVPTtB

And the token here:

https://alpha.aergoscan.io/account/AmhRkoGANw6FKpTbLXBsh2K2MMdvNzBem2mqGtKRqH3ShaeWn2ay?tab=interactive

It does not appear on the tokens tab, and above we can see it is not recognized as an ARC1 token properly (no token details)

In the "Interactive" tab (when displaying a contract) some functions can only be called via a "call" / using a transaction.

Suggestion

When we click on the button it could pop up the Aergo Connect with a proper transaction to be signed.

It makes it easier to interact with the contract

The aergoscan can check in the ABI which ones are "query" and which ones are "call" and show the button caption accordingly.

The problem: some contracts are deployed using abi.register for all the functions, query included. In these cases the query functions would appear as requiring a call, but they do not...

One solution:

• If the function is marked as query, treat it as query (show the query button)
• If the function is marked as call, it can try to make a query first and if it fails, then it creates a transaction and sends it to the aergo connect app

Looking for accounts in the meta db has some shortcomings: you can't find accounts allocated at genesis, you can't find newly created contracts. Why don't we just parse the input, see if it is a valid address, and if so ask the fullnode if the account exists.

Currently the mint and burn operations are displayed on the Transfers tab using the address0 (or 111111...) as the source or destination:

It is a bit confusing to understand what is going on, mainly for newbies.

What about instead of the "11111" use descriptive names like "MINT" and "BURN"?

But as some accounts may have names and the names can be displayed instead of the address, maybe instead of just "mint" and "burn" it could use some differing marks, like "<<MINT>>" or whatever, using characters that are not allowed in the account names.

Or even using different color either for the row background or for the text foreground.

This can be implemented after this is done

The same could also be applied to events from the WAERGO contract. It has events named "wrap" and "unwrap"

It is common for teams to create a token and lock parts of the supply so that they can only be used after some expiration time. This can be done in Aergo using the Token Locker

It makes more sense for tokens with fixed supply (those that are not mintable). In this case the team cannot mint new tokens and they can only use that fixed supply, in which some part they locked for future use.

The team can prove to investors that some amount of the tokens are really locked by using the Token Locker.

The Aergoscan could read that information of locked tokens directly from the Token Locker contract, and display it on the token page:

• Circulating supply ( = total_supply - locked_supply )
• Locked supply ( retrieved from the token locker )
• Total Supply ( retrieved from the ARC1 contract )

To read the locked amount on the token locker:

local amount = contract.call(token_locker, "get_total_locked", token_address)

It will return the amount that is really locked, ie: in which the locks did not expire (at this moment).

When the user clicks on the locked supply, Aergoscan can retrieve details of the locked tokens, like the expiration time for each amount, and display in a popup using a chart.

This information can be retrieved with:

local locks_str = contract.call(token_locker, "locks_per_token", token_address)

It returns a JSON string with information about each lock, mainly amount and
expiration_time. This last one in unix timestamp, that can be converted to a UTC datetime for display.

For external apps it would be useful to be able to point to a /search?q= route that displays all possible parsings pf the query, similar to the search bar but as page.

The backend currently doesn't work with multiple blockchains. Since multi-chain is an important feature of Aergo, we need to improve this.

There are two approaches:

• Have one instance of backend+frontend per chain (optionally reuse same db, with index prefix)
• Have multiple chains in one instance (more flexible with UX, e.g. we can have a dropdown to switch between networks and also analyze cross-network traffic)

References:

• https://github.com/aergoio/ARC1Token
• https://github.com/aergoio/ARC2NFT

Issue in Aergo Connect: aergoio/wallet-extension#19

Stream on homepage may fail for different reasons, mostly because the node is not receiving blocks. This could be an error, or the "pre launch" state of a new chain. It would be good to at least display the most recent block in that case, so that the site doesn't look broken (block 0 in the case of "pre launch").

So, add a one-off call to get the best block, either if stream fails to load or maybe just always (could be faster than the stream, so less time to display useful data to the user)

Most tokens should be created through the ARC1 Factory, to increase the trust in the created tokens. Once a token is created by the factory, we know that the code is not modified so we can have a higher degree of trust on them.

Tokens created without the factory do not have the same security guarantees

Proposal

To implement a contract code verification on AergoScan

It would be used for those tokens created outside the factory

In these cases the token creator (or anyone) can send the contract code and then it is compiled by AergoScan and the bytecode is compared to the deployed one. If it is the same, the contract code can then be displayed on the token page on AergoScan, for anyone interested in reviewing it

When looking for a smart contract events using aergoscan (and also via GRPC) it is very slow to load events as the current method scan many blocks searching for events from the contract.

The events tab generally shows no event, even when we click on "load more" many times. This is because there are so many blocks and to get an event from just 3-7 days ago we would need to click that button many many times.

Proposal

The indexer could save the list of events for each contract on a database.

It would be good for 2 reasons:

• It would be faster to retrieve past events from contracts
• It can help make the indexing faster, by keeping these events on the first pass (parallel) and only when finished processing all the blocks (and having contract info) they can process the events

The storage could be in a SQLite database, named something like events.db, using the contract address as the name of the table (to minimize storage size) and other data in the table itself, like:

CREATE TABLE Am.... (
  block_number INTEGER,
  event_id INTEGER,
  event_name TEXT,
  arguments TEXT,
  PRIMARY KEY(block_number, event_id)
)

The block number cannot be the primary key because the contract can emit more than one event on the same block.

Querying this database would be so much faster than querying the blockchain, because the aergo blockchain did not include indexing of the events.

If it is too much data to be stored on the database, then we can store just the block_number:

CREATE TABLE Am.... (
  block_number INTEGER PRIMARY KEY
)

In this case the database would have, for each contract, a list of blockno that generated at least 1 event.

And then aergoscan can retrieve the blockno from the database and then retrieve the events from the blockchain using the block number (faster than scanning thousands of blocks)

API

The new API to retrieve the events from a contract could be different: instead of querying by block range, we could query by "the last N events", and then "the next N events" using an offset.

In this case it would be guaranteed that some events would be retrieved in a single query

With the name system in place (mappings of name --> address), it would be good to be able to do reverse lookups (address --> name).

Need to create a new index and fill it with data from transactions.

We can either go through all transactions as they come in, or maybe we can add tx type and first few bytes of payload to the existing tx index to be able to filter more easily afterwards..?

Currently, the tx view doesn't show the timestamp because that information is not transmitted from the node when requesting tx info. To see the date, currently users need to click through to the block.

We can either get the block on the tx page, or we can use the esindex to get that information.

It would be used to search for a given token by name or symbol

Input:

String

Output:

List of tokens in which the name OR symbol match the input

The match can be partial, like "starts with", so if the user types "A" the API would return all tokens in which the name or symbol starts with "A".

For each item in the list, returns:

• address
• name
• symbol

When a token is created, the user may want to assign a logo to it. As images are not stored on chain, we need some standardized way to store and retrieve them.

This is a discussion, so you can leave your ideas below

Where to store

1. In a database managed by aergoscan
2. Using IPFS or Filecoin
   a. retrieve directly from them (probably slow)
   b. keep a cache on aergoscan
3. ...

Interface to set the logo

Maybe in the same interface to create the token.
With a screen to update the logo image.

How to limit the logo update to the token owner/manager?

1. The owner can set a logo hash on the token
2. The owner can set a logo path on the token. It can be an URL to IPFS or Filecoin
3. Identify the owner by signing a message. It should match the _owner on the token contract
4. ...

API to retrieve

Given a token address, retrieve the image. It can be a REST API

Currently, blocks only know the producer's pubkey, but the p2p protocol works with peer ids (as seen in the peer list and voting statistics).

The peer id can be calculated from the pubkey (I just haven't quite figured out how, yet).

So, we can translate a block's pubkey to a peer id and then match that with the rest of the data.

The token factory contract is being identified as an ARC2 on alphanet:

https://alpha.aergoscan.io/account/Amgu52QrSVmLMJ8DMZnksNEgY164AaMKihCeowzVcmz6KQz5xXp2/?tab=interactive

At the moment, the search field just tries to guess what the user could have meant based on the format, which obviously fails because it's impossible to differentiate types of hashes just based on the string.

There should be a search API end point that looks through the database for addresses, tx and block hashes