Reading Nervos Blog post on CKB VM V1 Upgrade, in the section Exec Syscall Auth library #37 is pointed at as a good example of exec syscall application.

The markdown doc linked in the auth library PR reads:

High Level APIs
The following API can combine the low level APIs together:

int ckb_auth(EntryType* entry, CkbAuthType *id, uint8_t *signature, uint32_t signature_size, const uint8_t *message32)
Most of developers only need to use this function without knowing the low level APIs.

So my questions are:
1) Is this API stable? Can I safely base iCKB scripts on it?
2) Is it already deployed on main-net? If so, what's the Auth library cell address?

Keep up the great work 💪
Phroi

There are xudt/sudt cells with zero balance being created. For example: This CAT++ transaction, output 3 is an xudt cell with zero balance.

The creation of this type of cells either by mistakes or by intention are meaningless.
Restricting them can help keep CKB UTXO set minimal and lightweight.

I find it's difficult to figure out suitable tooling to deploy a script. It would be great if there is a tutorial or something like that to tell others how to deploy & use it.

CKB node reports error code with link to pages in https://github.com/nervosnetwork/ckb-script-error-codes, such as:

source: Outputs[0].Type, cause: ValidationFailure: see the error code -23 in the page https://nervosnetwork.github.io/ckb-script-error-codes/by-type-hash/25c29dc317811a6f6f3985a7a9ebc4838bd388d19d0feeecf0bcd60f6c0975bb.html#-23 })

But all the scripts in ckb-production-scripts have no corresponding pages in ckb-script-error-codes. Users have to search error codes in the source code themselves, which is very inconvenient.

Omni-lock is pushing for an upgrade, and I think this feature can be added by the way, which is to use ERC-712 to verify signatures from Ethereum wallets.
It might look like this:

CKB Transaction: 0x0000000000....

should add a new auth_id to verify the signature of ERC-712 message.

In addition to omni-lock, ckb-auth can also perform such upgrades.

1. We need to add checkings in build.rs file, to ensure the compiled xudt_rce binary does not change.
2. One different way, is that you can try updating ckb-c-stdlib, if the binary hash stays the same, we can safely upgrade, otherwise we will need to maintain different versions of ckb-c-stdlib
3. Update ckb_dlfcn.h to ckb-c-stdlib
4. merge changes from master