Questions about caver-js-ext-kas.. and I beg for your help

English Caver
1

Hello. This is Yoon who is a junior Klaytn developer.
I am developing a bridge solution to connect between NFT projects and metaverses that don’t support blockchain.

I have been developing a smart contract by referring to the three API documents below.

  1. klaytn/design/computation/computation-cost
  2. klaytn/design/transaction-fees
  3. SDK for caver-js extension

I recently developed the bulkMint function that mints NFTs all at once over the KIP17 standard.
After developing the bulkMint function, I confirmed the function works properly through the caver-js-ext-kas library and the Baobab testnet.
Since the test had been successful, so I sent a transaction that executed the bulkMint function to create 1000 NFTs in the Cypress mainnet.

At this point, the problem occurred.
Unfortunately, when I sent the transaction for the bulkMint function on Dec. 09, 2021, the Klaytnscope didn’t work properly.
So, I could not check the transaction with “ErrOpcodeCntLimitReached” in the Klaytnscope.
Because I thought that transaction would not be sent due to lack of gas, I just increased the allowed amount of gas to 19,982,400,000 and ran the bulkMint function again.

My new transaction was executed by the Klaytn node with “ErrOpcodeCntLimitReached” sorrowfully…
Consequently, I spent more than 500 klaytn to send the wrong transaction.
(Klaytnscope,
Klaytnscope)

So… in order to prevent such mistake that I did,
Could you add an exception handler in caver-js-ext-kas’s contract.send()?
The exception handler checks whether the transaction exceeds the opcode limit before sending transactions to the network.
(I know the Klaytn provides klay_estimateComputationCost for opcode estimation.)

In addition… I’m really sorry to beg you for such a rude thing, but…
Is it possible to support or… restore Klaytn to continue development?
For the future development, I need at least some of Klaytn, which was destroyed by my mistake.

Thanks for reading…
Yoon.

2

Hi
I read what you posted.
The requested exception handling can be known only by executing it through the EVM.
Therefore, I don’t think it’s appropriate for adding the exception handling to go into the SDK.
Before sending, use call to check whether it is executable or not.
And unfortunately KLAY cannot be restored.

3

KEVM expands opcode limit (from 256 to 1,000,000,000) to accelerate the transaction confirmation in comparison with EVM.

However, the caver api does not provide any safety or exceptional handler to prevent op code lmit exception. It might occur the situation that spends lots of Klay for checking an opcode limit exception.

I think that the library developer should guide exceptional situations that may occur while using the library through the documentation.

Then, it would be nice to display a warning text about the opcode limit at the top of the api document at least.
Typically, contract developers think that the limit of opcode is 256 not 1,000,000,000.

Thank you.
Yoon.