0xsequence / ethkit Goto Github PK

I was trying a batch call with 4 calls, CodeAt and three function read calls, its way faster to call them seperately concurrently than doing a batch call for some reason, could be node do slower responses to batch calls but maybe a ethrpc problem

I haven't tried this, but I think if topics are specified, then it's possible to receive no logs, while the logs bloom filter is non-zero. This means the block is never considered backfilled and causes the monitor to hang if logs are requested.

github.com/0xsequence/ethkit v1.22.4

SolidityPack seems to not consider negative signs:

entry1, err := ethcoder.SolidityPackHex([]string{"int32"}, []interface{}{int32(-42)})
entry2, err := ethcoder.SolidityPackHex([]string{"int32"}, []interface{}{int32(42)})
fmt.Println(entry1)
fmt.Println(entry2)
// entry1 == entry2

yields 0x0000002a, 0x0000002a

Other integer-types seem to show the same issue.

comparing to ethers/utils/solidity.ts:

let v1 = ethers.utils.solidityPack(["int32"], [-42]);
let v2 = ethers.utils.solidityPack(["int32"], [42]);
console.log(v1);
console.log(v2);

yields 0xffffffd6, 0x0000002a

Above line should be:

blocks = blocks[len(blocks)-c.retentionLimit-1:] 

updated len(blocks) after above change:

updatedLength = len(blocks)-1 - (len(blocks)-c.retentionLimit-1)
= c.retentionLimit

for example, consider blocks to be slice with length=150 and c.retentionLimit=100 then current code will do this:

blocks = blocks[99:] //blocks will end up with length = 50 (=len(blocks)-retentionLimit)

with change:

blocks = blocks[49:] //blocks will have length = 100 (=retentionLimit)