I've been looking over the zkcheckout docs here: https://zksync.io/api/sdk/checkout/tutorial.html#structure-of-the-tutorial
Say as a merchant I want to accept payments to one address would that be okay due to the descriptions being used as a sort of payment id, are these part of the transaction or only informational?
const transactions = [
{
to: '<your-eth-address>',
token: 'DAI',
// The amount should be specified in wei
amount: '23000000000000000000',
description: 'For apples'
},]
I also see: https://zksync.io/api/sdk/checkout/types.html#zksynctransaction
it's a bit confusing what is meant here:
description — the transaction description. For now, it is only used when semanticType is set to 'FeeOrCommission', and is ignored otherwise.
Does that mean the field is ignored if semanticType isn't feeOrCommision? Accepting an incoming payment isn't necessarily taking a fee but in my case a description would be needed to tie different payments to different orders would preferably have an order id set in the description.
There are also long delays between blocks here: https://zkscan.io/explorer/
Is that just due to not committing on chain if there are not many transactions ?
I also see: https://zksync.io/api/sdk/checkout/types.html#zksynctransaction
it's a bit confusing what is meant here:
description — the transaction description. For now, it is only used when semanticType is set to 'FeeOrCommission', and is ignored otherwise.Does that mean the field is ignored if semanticType isn't feeOrCommision? Accepting an incoming payment isn't necessarily taking a fee but in my case a description would be needed to tie different payments to different orders would preferably have an order id set in the description.
Hi!
That is a typo, the docs need to updated. The description is shown for normal transactions as well
I've been looking over the zkcheckout docs here: https://zksync.io/api/sdk/checkout/tutorial.html#structure-of-the-tutorial
Say as a merchant I want to accept payments to one address would that be okay due to the descriptions being used as a sort of payment id, are these part of the transaction or only informational?
const transactions = [
{
to: '<your-eth-address>',
token: 'DAI',
// The amount should be specified in wei
amount: '23000000000000000000',
description: 'For apples'
},]
These parts are only informational (except for the recipient's address, the amount and the token in which the transaction will occur). The description is mostly for the convenience of the users.
There are also long delays between blocks here: https://zkscan.io/explorer/
Is that just due to not committing on chain if there are not many transactions ?
We don't commit onchain until a certain timeout passes or there are enough transactions in the blocks (we usually commit multiple blocks at a time)
I've seen it happen all the time with currencies that have payment IDs. Normally you don't need one for transactions so in the cases where the user needs to include it it's easy to mess up.
is there a call for zksync that mimics
eth_blockNumber?
Hi! There is a similar call: https://rinkeby-api.zksync.io/api/v0.1/status
An example of the usage can be found here: https://zksync.io/api/v0.1.html#introduction-2
is there zksync token?
Not yet :)
Hey @juscamarena ! Thanks for the feedback. Could you please explain in more detail why do you need payment id and why transaction hash on its own is not sufficient?
Unless payments are interactive, I need to be able to receive payments from different users to the same address, issues come up if I use different addresses as currently, I'd have to link up each on to L1 before sweeping all these to one wallet. The operational flow would be much better having a payment id.
It had some vague similarities to how zkRollups work if I recall correctly
I have never read about Zether, but I'll read about it later.
What I can tell is that it is non-trivial to implement private transactions with zkRollups, since the word "rollup" stands for sending all the transactions on-chain (so that anyone can restore state). But there are a lot of papers describing anonymous transactions, so I am very sure there is something that can be integrated with zkRollups.
IMHO the fact that rollups require on-chain data availability may not be an issue in the future if zkPorter (https://medium.com/matter-labs/zkporter-composable-scalability-in-l2-beyond-zkrollup-2a30c4d69a75) is implemented.
But I am not a cryptographer so it is hard for me to judge what is easy to implement and what is not, but I am sure that privacy will not be a hard task once a certain level of scalability is reached since that is what ZKPs are for :)
Hey @juscamarena ! Thanks for the feedback. Could you please explain in more detail why do you need payment id and why transaction hash on its own is not sufficient?
Unless payments are interactive, I need to be able to receive payments from different users to the same address, issues come up if I use different addresses as currently, I'd have to link up each on to L1 before sweeping all these to one wallet. The operational flow would be much better having a payment id.
Sorry, but I still don't fully get it. An id is a unique identifier of a payment, which the transaction hash is.
When a user pays some funds during the checkout the merchant's webpage receives the transaction hash via which the payment was done. This hash can be processed by the merchant (check on the backend that the transaction is valid and has indeed succeeded) and stored in the DB afterward.
So each payment does have a unique identifiter.
Payment IDs are given to customers first, then customers make a payment using that ID. You know in advance which IDs belong to each customer and purchase they made, so you know if that purchase has been paid, and if that specific customer has sent the money.
It's important that clients can set Payment IDs arbitrarily, otherwise this doesn't work.
@StanislavBreadless I don't see how the hash can replace payment IDs for merchants. Maybe you misunderstood the context. But the problem is not having a unique identifier for each transaction that is made on the chain, the issue is tying each transaction to an individual customer and individual purchase. The transaction ID doesn't say anything about that.
Payment IDs are given to customers first, then customers make a payment using that ID. You know in advance which IDs belong to each customer and purchase they made, so you know if that purchase has been paid, and if that specific customer has sent the money.
It's important that clients can set Payment IDs arbitrarily, otherwise this doesn't work.
yes, 100%!
Payment IDs are just a tag added to a transaction, it could be implemented easily in different ways. But the main issue is having a standard that all merchants and wallets will support.
Exactly, and this is why there isn't one for base chain ETH, even if a standard were created now, no wallets would support it and it would take years for any adoption.
