godwokenrises / light-godwoken Goto Github PK

The problem

Currently, whenever the current network changes from a supported network to an unsupported network, godwoken-bridge requests to switch the current network to a supported one, which can be too aggressive as it can be triggered even if the user was focusing on other apps.

Maybe when we detect a network change, we should notify and ask the user to switch the network first, instead of requesting the switch directly. An example of the process:

1. Detect if the current network changes to an unsupported network
2. If it does, ask to switch the network via confirm dialog
3. If confirmed, request to switch the network

Contributors

Thanks to @gpBlockchain @Dawn-githup for pointing out the issue.

####Steps to reproduce the behavior:
1.V0 initiates a withdrawal to v1
2.The transaction history will be displayed in both v0WithdrawalHistory and v1DepositHistory

####According to the light-godoken display rule, only one item needs to be displayed

This data is obtained from scan
getDepositHistories:

getWithdrawalHistories

Describe the bug

L1 Transaction ckb cannot directly trade after clicking max

Steps to reproduce the behavior:
1.See the following figure for details

When making a withdrawal to L1 from Godwoken Bridge, the default time is always 7 days. But in practice it is usually longer, around 10 days.

In the Godwoken documentation (https://docs.godwoken.io/gwchangelog/v0difv1) there is a remaining time interval between 8 and 12 days, depending on the status of the network.

Some ideas:

• Show as estimated remaining time the minimum possible, 8 days + third proposal.

• Show as estimated remaining time the average time between 8 and 12, which would be 10 days + third proposal.

• Introduce a textbox that informs the user that the remaining time is variable and not fixed and therefore it can take between 8/12 days. Inside [Pending], for example.

Thank you!

The Godwoken Bridge UI could use some time to do the refactor work, such as refactoring from using StyledComponents to using TailwindCSS. But before this, there are actually tons of UI/CSS frameworks to be selected:

• TaildwindCSS
• Maintine
• RedwoodJS
• Charkra

Sorry about mixing them together, I will take some time to look these frameworks out.
Aside with these UI/CSS frameworks, we also have @ricons that can be used as our SVG icon library.

Also, the version of React can be updated to Vite+React18.

Describe the bug

V0 quick withdrawal is displayed in the pending list for 1 day+

Steps to reproduce the behavior:

1. V0 withdrawal ——> godwoken v1

Steps to reproduce the behavior:

1.Send Dobby deposit transactions continuously
2.Refresh Page

Declined deals in the completed list will appear at the top

A user has reported a strange issue. He had four request withdrawals with active countdowns, and today one of them, the last one, has disappeared. He can't see it in either YokaiSwap or Godwoken Bridge.

Looking how to reproduce the problem, I have made several test request withdrawals with 400 CKB through https://bridge.godwoken.io/ and they do not appear in pending, but the 400 CKB disappear from the L2 balance. The user has also done it to test it and the same thing happens to him.

Describe the bug

Some controls in light-godwoken on ios14 are inconvenient to click

Steps to reproduce the behavior:

1. Open light godtoken in Metamask browser

1. Top left logo overlap
2. The two controls in the lower left corner are inconvenient to click

For example, this logo url has failed, we might have to look it up:
https://cryptologos.cc/logos/nervos-network-ckb-logo.svg?v=002

[Estimated time left] should be about 7 days

Describe the bug

Open light-godowkne on ios and click on the QR code of the account address, a 'Check QR code' will be displayed on the QR code

Steps to reproduce the behavior:

1. Open light-godowkne on ios
2. click on the QR code of the account address

'Check QR code' will be displayed on the QR code

Describe the bug

Withdraw exceeds its own balance without prompting 'Insufficient CKB Amount'

Steps to reproduce the behavior:

1. Withdrawal amount exceeds own balance
2. Initiate a withdrawal

expect

Insufficient CKB Amount

I have a user with the following problem:

Made a CKB withdrawal from L2 Godwoken V0 to L1 Nervos using Safepal CKB Bridge. That is, he did not use the YokaiSwap interface to make the withdrawal, but the Safepal interface. That interface, CKB Bridge, no longer exists today. After many attempts, he managed to activate the withdrawal manually but the funds never arrived at L1 and it disappeared from the Safepal withdrawal history, which makes me think that the withdrawal was not really activated and is still blocked (in the TXID it can be seen that the funds are in a middleware address). The user contacted Safepal support but they have not been able to fix it. He has checked if his withdrawal appears on Godwoken Bridge and YokaiSwap, and it does not appear on the interface.

The problem reminds me a lot of that of this other user. The main difference is that he made the withdrawal through YokaiSwap and not from Safepal CKB Bridge.

https://discord.com/channels/657799690070523914/671648403071172619/1022503232498585670

I thought that perhaps we can apply the same solution as to the other user, and he can finally access his funds.

I have sent you a DM via discord @Flouse with the TXID and the addresses of the user to safeguard his privacy, my tag is AlejandroR # 9014 in discord.

Thank you.

Describe the bug

L1 has no ckb, and Get Test Token (TTKN) on L1 has no prompt

Steps to reproduce the behavior:

1. L1 has no ckb
2. Get Test Token

expect

Give corresponding prompt information

Describe the bug

L1 Transaction Youkai token shows the capacity of other tokens

Steps to reproduce the behavior:
1.See the following figure for details

Describe the bug

Rejected deals will always show up in the Pending list

Steps to reproduce the behavior:

1. Send two transactions in a row
2. A double spend occurs and one of the transactions is rejected
3. View rejected transactions at godwoken-bridge

rejected transaction https://explorer.nervos.org/transaction/0x26716127fdd1b923235d1ce6e3ba8e2422118f3b3bfce61e57f09d4068bd4139

Steps to reproduce the behavior:
1.Currently applied to network mismatch
2.Turn off the prompt of switching network within the application and switch to other pages within the application
3.You should not prompt frequently when switching pages within the application

Youkai

godwoken-bridge

Godwoken exposes the config of the mainnet, so we can update the mainnet config. GodwokenExplorer also exposed the mainnet config of Godwoken

• Godwoken: https://github.com/nervosnetwork/godwoken-info/tree/mainnet_v1/mainnet_v1
• Godwoken Explorer: https://github.com/Magickbase/ckb-wallet-and-explorer/wiki/Godwoken-Explorer

I think the mainnet RPC has rate limit.

Describe the bug

The Deposit transaction signature message in ios14 displays garbled characters

Steps to reproduce the behavior:

1. Initiate deposit transaction in Metamask browser
2. Jump to signature page

Describe the bug

'Get 1000 Test Token (TTKN) on L1' Data duplication error occurs after two consecutive operations

Steps to reproduce the behavior:

1. "Get 1000 Test Tokens (TTKN) on L1" twice in a row

Error prompt appears

 JSONRPCError: server error {"code":-1107,"message":"PoolRejectedDuplicatedTransaction: Transaction(Byte32(0xe233d9171f944bd43e145cf98d45f19e6c03483112a0338323e62632fcc42690)) already exist in transaction_pool","data":"Duplicated(Byte32(0xe233d9171f944bd43e145cf98d45f19e6c03483112a0338323e62632fcc42690))"}

The feature

We've found a difference behaviour in LightGodwokenV0 and LightGodwokenV1:

• V0 - The app works without adding a v0 network to the provider (the connected wallet)
• V1 - The app needs to get L2 balance from the provider, therefore it has to add a v1 network to the provider

This single difference between v0 and v1 can be erased if we can just request the L2 balance from L2 RPC directly in v0 and v1, instead of requesting from the provider. But there might be other methods with the same issue.

So we need to spend more time reviewing the light-godwoken SDK, and think about how to make the SDK better from a larger perspective. If we could remove all dependencies on the provider (except for signing messages), maybe we don't have to add any network to the provider. This can be the next thing we do.

But on the other hand, if the app does not add a network to the provider, when the user wants to transfer L2 assets to others, do they have to add the network by themselves? It seems like a downside to the feature. @Flouse

Related segments

• LightGodwokenV0 - https://github.com/godwokenrises/light-godwoken/blob/develop/packages/light-godwoken/src/LightGodwokenV0.ts#L100-L104
• LightGodwokenV1 - https://github.com/godwokenrises/light-godwoken/blob/develop/packages/light-godwoken/src/LightGodwokenV1.ts#L98-L101

One of the apps - https://app.hadouken.finance/ - deployed on Godwoken Mainnet v0 is using dCKB. It would be great if Godwoken Bridge also supported dCKB (both on Testnet and Mainnet).

dCKB erc20 address on testnet v1.1: 0x7e54f7324902B72334827F40f613116F06a88845 (https://nervos.gitbook.io/layer-2-evm/ecosystem/tokens)

The issue

The current version of godwoken-bridge can easily trigger a double spend error when constructing an L1 transaction (deposit/l1-transfer/claim-test-sudt). Here's how to reproduce one:

1. Open Godwoken Bridge Testnet
2. Deposit a certain amount of CKB to L2
3. Deposit again after sending the fist deposit (do it fast)

How it happens

Note that to reproduce the error, the second deposit needs to be sent fast, and then you should receive an error that indicates the transaction was double-spent. More detailed speaking, some inputs in the second transaction was double-spent.

But why would any cell in the inputs of a transaction trigger a double-spend error? Let's see how the construction works. When an L1 transaction is constructing, it collects live cells from the sender's address to build outputs and pay transaction fee:

• Collect pure CKB cells
• Collect sUDT cells if transferring sUDT
• Collect sUDT cells with free CKB in them

Normally when constructing the first transaction, everthing should be fine. But CKB needs time to handle the first transaction, and when you construct the second transaction too fast, while constructing, light-godwoken could collect repeated input cells just like in the first transaction. This is how double-spending works in L1 transactions, you're literally trying to spend the same cell twice.

How to solve it

1. Mange a spent cells list
   We can manage a spent cells list locally, and exclude those spent cells when collecting input cells. This is an simple idea of how we can do it, in the actual designing/coding phase it could be more difficult to control, as a transaction can be rejected after it is sent.
2. Freeze the page when processing a transaction
   Or there's another way, we can simply disable L1 transaction features when there is any L1 transaction processing on-chain. However, none of these methods prevent double-spending triggered from multiple tabs.
3. Use ckb-lumos/transaction-manager
   This method is relatively similar to the first method, only it is controlled by the ckb-lumos library automatically. Since we're using ckb-lumos everywhere in light-godwoken, and the package is easy to replace things in our code, I think this is the best solution for us. Check the link of the package for more details: @ckb-lumos/transaction-manager.

godwokenrises/godwoken-info#41
nervosnetwork/force-bridge-ui#113

The Confirm button does not work when the current network is matched to the bridge. How to reproduce:

1. Switch to any network but Godowken Testnet V1 in MetaMask
2. Open Godwoken Bridge Testnet (https://testnet.bridge.godwoken.io)
3. When the Network Mismatch dialog pops up, switch to Godwoken Testnet V1 in MetaMask
4. Click the Confirm button in the Network Mismatch dialog, nothing happens

deposit 0.1 COOP transaction：https://explorer.nervos.org/transaction/0xb4f18343befbf7e90aac35d0f8993bf7599f5fa2d59658bd915a405e3cac8ba1
deposit 1 COOP transaction：https://explorer.nervos.org/transaction/0x68adff5ea5c8d34d6deaa9c066548badd5148d2137d9d4f7c58f2ae6e1e501c7

Steps to reproduce the behavior:

1.Continuously submitting multiple withdrawal requests.
2.Unprocessed withdrawal requests (e.g. failed over withdrawal) will remain in the history record.

Transaction hash： 0x81dd4415e37eee1d7581f1f5e9c18e9a388a9606d8984715cb10d6bcca3a7ad5

After sending a withdrawal_request, the Withdrawal Pending List took about 5 minutes to display the new pending withdrawal.
It would be better to show the status of the new pending withdrawal as soon as possible.

Suggested solution

We could use gw_get_withdrawal RPC to get the status of a new withdrawal request.

echo '{
    "id": 2,
    "jsonrpc": "2.0",
    "method": "gw_get_withdrawal",
    "params": ["Withdrawal Tx HASH"]
}' \
| tr -d '\n' \
| curl -H 'content-type: application/json' -d @- \
https://godwoken-testnet-v1.ckbapp.dev

Godwoken finality mechanism will be changed by

• godwokenrises/godwoken-scripts#132
• godwokenrises/godwoken#836

Interpretation of WithdrawalLockArgs.withdrawal_block_timepoint changed

• https://github.com/godwokenrises/godwoken/blob/develop/docs/finality_mechanism_changes.md

Some low priority features from the previous season are still on hold, and I think we can finish them before the next release:

• Link addresses to certain explorers
• Add friendly-tips for users with Javascript disabled

Describe the bug

The page cannot be closed due to insufficient withdrawal token sent

To Reproduce

Steps to reproduce the behavior:

1. Select withdelawal
2. Select all ckbs
3. Select a Token 'pckb= 20'
4. Request Withdrawal

Expected behavior
error messang： Finalized simple UDT custodian cell is not enough to withdraw
Confirm Request page can be closed

Screenshots or Logs

no error message
The confirmation request page cannot be closed

Error: JSONRPCError: server error {"code":-32007,"message":"Withdrawal fund are still finalizing, please try again later. error: Finalized simple UDT custodian cell is not enough to withdraw"}

Deposit query functions in light-godwoken is not working properly because we're using the old version of @ckb-lumos. We need to upgrade the version of relevant packages, so then our app can back to normal.

Note that the latest version of the library have breaking changes, check for more details:

• https://lumos-website.vercel.app/migrations/migrate-to-v0.19
• #182

Currently a user who uses https://bridge.godwoken.io/ to perform the withdrawal from L2 to L1 has to use YokaiSwap (https://v1.yokaiswap.com/bridge/transfer) or another third-party app to send from L1 Wallet address to a deposit address of a CEX or their Wallet (PortalWallet, Neuron, etc). In my opinion, users should be able to do all the withdrawal steps, including sending to their CEX or wallet or other L1 address from the public architecture and not depend on third parties/apps. It also involves an extra step (change app), which decreases the user experience. I wonder if it is possible to add this functionality to the bridge.

In this way we could avoid this:

Thank you!

Describe the bug

Deposit/Withdraw canceling signature in metamask prompts unknown error

To Reproduce

Steps to reproduce the behavior:

1. Initiate a deposit or withdrawal
2. Unsign with metamask

Could be more specific

Steps to reproduce the behavior:

1.Initiate multiple transactions in succession
2.Error prompt:Unknown Error, Please try again later

Error: {"code":-301,"message":"TransactionFailedToResolve: Resolve failed Unknown(OutPoint(0x716d254d7cf85b26e83664a0ef89820126e344cfa8b3288855d3bcc10464928a01000000))","data":"Resolve(Unknown(OutPoint(0x716d254d7cf85b26e83664a0ef89820126e344cfa8b3288855d3bcc10464928a01000000)))"}

The current error prompt is not detailed enough, and the prompt information needs to be optimized

Expected: Bridge allows to withdraw from Godwoken v0 all tokens that are available in Force Bridge (both on testnet and mainnet).

Actual: Only ETH (from Force Bridge), TAI and USDC (not from Force Bridge) are possible to withdraw.

Screenshot from mainnet deployment:

Deprecating old Godwoken v0 testnet

The testnet_v0 of Godwoken is officially deprecated.

We should keep up with:

• Remove v0 testcases from light-godwoken or any replacement? @homura @Flouse
• Disable actions on testnet_v0 pages

Background:

• A feature: The User can cancel a deposit if the deposit is not packed by roll-up after a range of time, which is determined by the deposit lock contract. For godwoken v0, it's 20 minutes, and for v1, it's 7 days.

Why:

• We have already supported the "cancel deposit" functionality, but it's a problem for testers to test this feature since it takes too long to wait for the deposit to expire. If a user can configure expiration time, it's great to test cancel deposit.

How:

1. go to Godwoken Bridge: https://light-godwoken-git-advanced-settings-cryptape.vercel.app/#/v1
2. open developer tools in browser and navigate to Application, find local storage in left panel:

FAQ:

• Why other deposit histories are gone after I changed this setting?
  • Modifying cancel_timeout will change the deposit lock for the current account, so that the assets deposited to the original deposit lock can't be indexed here. Reset(or remove) the advanced settings to go back to normal mode.

####Steps to reproduce the behavior:
Check deposit after a period of time after I initiate multiple deposits_ History
It is found that the completed transaction is still in the Pending list

At present, there is only one account with this problem

Ethereum Address: 0xcf5dccb5ceaddaeebf36affd16d5a4bd1ffa5193

https://pudge.explorer.nervos.org/transaction/0x024424f68671995bfbc57c8bac96d77c81667c2554bcd844ca956b06bdc3a166

Describe the bug

Some tokens have no logo

To Reproduce

Steps to reproduce the behavior:

1. Select Token
2. Token without logo 'YOK,COOP,TAI'

Describe the bug

The transaction returned by the Withdraw request hx stays permanently

Steps to reproduce the behavior:

1. Initiate a withdrawal
2. return transaction hx

expect

Can be set to not stay permanently

Describe the bug

Withdrawal Confirmation Request page, the signature page cannot be closed after being pulled down to close

Steps to reproduce the behavior:

1. Send a Withdrawal request
2. Drop down and close the Metamask signature page

3. Pull down and close at the position shown in the figure above

Withdrawal Confirmation Request page click X cannot close the page

We use gwscan api to query the user's withdrawal history, and recently I found out that the withdrawal_histories api that we're using, has a pagination. We should take a look at the details around it.

Describe the bug

L1 Transfer Completed list is missing the success identifier

Problem Pr: #224

Steps to reproduce the behavior:
1.See the following figure for details

Right now, light-godwoken (the repo) is a normal repo with two parts of code mixed together:

• LightGodwoken (package)
• GodwokenBridge (app)

We think it's time to separate the two parts of code for better management, here's how:

1. Refactor the repo to a monorepo
2. Separate packages and apps into specific folders
3. Publish LightGodwoken as an SDK library for developers to use

Right now it is difficult for us to know what specific version we are running on godwoken-bridge's testnet/mainnet.

We want to change that, and here we have an example: ForceBridge.
On ForceBridge there is an "About" button that shows the current commit hash for the site, I think we can do it like they do, too.