Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Justin Camarena
    @juscamarena
    hey!
    Justin Camarena
    @juscamarena

    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.

    Justin Camarena
    @juscamarena

    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 ?

    Stanislav Bezkorovainyi
    @StanislavBreadless

    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)

    reasv
    @reasv
    There's mention of privacy on the zksync site, but nothing about how it would be implemented or the characteristics of the privacy scheme.
    Is there anywhere I can know more about how private zksync would be in the future?
    And what would be the methods used to implement it
    Justin Camarena
    @juscamarena
    Thanks for the answers, I'd really really recommend having some sort of payment id support for normal transfers. I work for a merchant accepting ETH on L1 and most of our struggles seem to be no standard payment support for receiving payments to the same address for ETH and tokens.
    Maybe even better if it were a memo field committed with the transaction
    I'm sure this is a huge fee pain point for exchanges as well, enormous amounts of fees are spent by exchanges trying to sweep tokens from deposit addresses due to them requiring new deposit address for each user.
    I think there'd be enormous benefits of scale if any L2 added this kind of support, otherwise, merchants/exchanges will need to generate new addresses for each new payment
    reasv
    @reasv
    I understand that this is a problem for merchants, but having a payment ID can be incredibly frustrating for users because it's easy to make a mistake and not include it.
    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.
    Whereas for the account ID, it's always used and it's also required
    Ideally there would be some system where "virtual account IDs" are generated that also contain payment IDs in them, but all the money just goes to one account
    In some sense bitcoin has this, because Bitcoin many bitcoin addresses belong to the same wallet. However with bitcoin you always have overhead when you receive money from many people due to the UTXO system
    Justin Camarena
    @juscamarena
    Yes, but it can be optional, as a merchant I'd show a QR code with the payment id included and or a button with a uri containing the address + payment id. I would not show an address so users would not send money to it without a payment id.
    I guess virtual account IDs could solve that, make it part of the address or a different address format that indicates it's a virtual address.
    I guess the only problem above is doing this before there are many wallet integrations as at that point good luck getting any wide support. QR uri encoding for example is a huge mess for ETH, wallets have their own flavor or integrate new standards while old wallets keep the bip21 style uris... It fragments everything making it hard to upgrade.
    Genysys
    @Genysys
    is there a call for zksync that mimics eth_blockNumber ?
    monkeyip
    @monkeyip
    is there zksync token?
    Stanislav Bezkorovainyi
    @StanislavBreadless

    And what would be the methods used to implement it

    Hi! Unfortunately, we can not provide any further details as the concrete protocols are yet to be developed. The methods are likely to be zero-knowledge proofs :)

    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?

    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 :)

    reasv
    @reasv
    I remember reading a whitepaper describing a privacy system for Ethereum based on zksnarks called Zether
    It had some vague similarities to how zkRollups work if I recall correctly
    This was a long time ago now though
    Are they in any way related?
    Greg Jeanmart
    @gjeanmart
    Hi guys,
    Hypothetical question. If I have a lot of transfers of tokens to do (like an airdrop). Would it make sense in terms of gas cost reduction to host the reserve of tokens on Zksync and perform a bunch of withdrawFromSyncToEthereum ?
    reasv
    @reasv
    moving a token from zkSync to Ethereum L1 is always gonna cost more than just sending the token to someone
    what you could do is do the airdrop entirely on zksync
    and send people tokens through zksync
    then they can withdraw if they want
    but they're the ones paying for that
    Greg Jeanmart
    @gjeanmart
    thanks, you right, I just checked: zksync withdrawal fees=$15 / erc20 transfer fee=$10 (50k gas/120gwei)
    Justin Camarena
    @juscamarena

    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.

    Currently, ETH has huge fees due to many exchanges inefficiently using new addresses for each deposit, an exchange then needs to aggregate all those funds at times sending ETH to sweep those funds in the first place (crazy), if there were a payment standard (or deposit one) things like this wouldn't be so much of an issue
    Stanislav Bezkorovainyi
    @StanislavBreadless

    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 :)

    Stanislav Bezkorovainyi
    @StanislavBreadless

    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.

    reasv
    @reasv
    @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.
    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.
    Justin Camarena
    @juscamarena
    I can't get the hash if a user pays via a QR code.

    @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.

    Dennis Gearon
    @kwince
    So read the following link and I understood about 60% of it. If I understand that much correctly then am I right that at the l2 merkle tree level, there is a fixed struct size for all the possible operations. There's no such thing as embedding any user data in it. Things like purchase order number and request order number for doing audits on sales. Is it possible to provide room for that kind of information in the records of a smart contract? On top of zksync using zinc?https://github.com/matter-labs/zksync/blob/master/docs/protocol.md
    Dennis Gearon
    @kwince
    So, the ETH chain has a recotd of all its transactis, the chain itsef. Same holds true for ZKsyncs chain of batches? Or does all THAT go into the ETH Chain (in CALLDATA) as well? How about the zinc contract method calls and their calldata? Any permanent record? Im trying to store some additional information with the payments that customers will be making into a contract that i will write. I would like the contract to be able to provess all the payments and additionsl information when it closes out, and rhen send a report.
    Dennis Gearon
    @kwince
    Also, i dont get how to assign to an array of a known size, but at an uknown till methid call time location. Tjinking of usingvarray to store the data abive in some kind of sequential assignment, but using only constants as array indexes (per the manual) i havent figured it out.