text:
Committing a database to the ledger without storing it on the ledger?
The Cardano blockchain has no global state, this means that shared state needs to be introduced. Is there a design pattern that lets you commit big sets of data to the ledger without storing it? This while still preserving the ability to later retrieve/change the data via proofs?

Is this a legit question or did you just want to answer your own question? How/why would you want to commit big sets of data and not have them saved on the ledger? I'm not clear on what you mean by 'commit' without storing to ledger.

I wanted to share my knowledge, it is common on SE. I had this question a few weeks ago and did some research on it, wanted to document it for others. With 'commit' I mean: publicly fix the database in a verifiable manner. Example: If I store a hash of a number onchain, and you try to guess my number, I can later reveal that number, and compare your guess. I committed to the number via its hash and cannot change it.

On the topic of why I would want this? Since Cardano only has local state, it is hard to track things, like the number of tokens mint by certain policy. You might want this data onchain for other scripts to use (without the use of oracles). This allows you to introduce such data, its a general design pattern common in crypto.
The core idea of this is to use the Cardano blockchain not as a database, but as a ledger to check if things are done in a valid way.

You can use Merkle tree's for this! This is an inverted tree like data structure that uses hashes to create a root hash that is uniquely defined by its leafs, the leafs are the nodes in the lowest layer here (1). Thus, with this root hash, you can commit a big set of data by only storing the root hash on the ledger (it is just a byte string).
This data structure also allows you to construct a proof that can prove that a leaf is a member of a Merkle tree, given only its root hash and this proof. These proofs are maximally of size log(n) where n is the number of leafs in the tree. A proof that a leaf is in the tree consists of giving a list of hashes for each layer of the tree. The hashes are not arbitrary, for each layer the hash is chosen that is needed for the path of the leaf that is proven to go up the tree. To visualize this,

Here, the data set is represented by the Tₙ, where n is a letter in the range A - H. The hashes of these Tₙ are Hₙ (these are the leafs). We see for example that going up one layer in the graph combines H_C and H_D into the hash H_{CD}. This combining of paired hashes keeps going until the upper layer is reached, this is the root hash H_{ABCDEFGH}. Note that changing any leaf (swapping leafs or change underlying data T) will result in a different root hash. This is because changing the input of a hash function gives in an entirely different output.
Now, to prove that the red leaf is in the green root, you have to provide for each layer two things. The first thing is a hash of the sibling node that together with the leaf you try to prove goes up the tree. The second thing is the position of these hashes relative to each other, left, or right. So, the proof that T_D is in the dataset with root H_{ABCDEFGH} takes the form.
[left H_C, Left H_{AB}, right H_{EFGH}]

To verify this proof, you can combine the hashes while taking note of the hash order (left or right), and compare it to the root hash.
H_{ABCDEFGH}=Hash(Hash(H_{AB},Hash(H_C,Hash(T_D))),H_{EFGH})

To utilize this structure on the ledger and provide a way to update a leaf using plutus, consider storing the root hash in a datum. This datum represents the commitment to the dataset and should be locked at a script with at least the following logic.
To verifiably update say leaf H_i from state T_i to state T'_i, you provide the validator three things in a redeemer when spending the UTxO that holds the root hash datum. These are the old state of that leaf, a proof that this old state is a member of the tree, and, a new root hash H' that is derived from the updated tree (where the old state of T_i is replaced with T'_i).
The validator only needs to check two things to accept the new root hash as the representation of the newly updated dataset,

The old state T_i is a member of the old root.
Given the new root H' and the proof of step 1, this proofs that the new state T'_i is a member of H'.

If these conditions are met, it is safe to update the datum to hold the root hash of the new state. Note that any arbitrary extra logic can be added to this (like mandating that the new output is sent to the same script address). This protocol works since a proof never contains a hash that is derived from the member you need to proof. So, changing the leaf that is being proved, still makes the proof valid for a root hash that is derived with this new leaf. Any change to other leafs renders this proof invalid.

Some last words, this design pattern is pretty cool as it lets you convert storage requirements to computation requirements on the ledger. Do note that this comes at a cost, that is, it obscures the data availability of the dataset since it is captured only in a hash. If the beginning state is publicly published, the current state of the dataset can be derived in a decentralized way by traversing the chain and logging the transaction that changed the state of the chain. This is cumbersome, but worth it for large databases.
With the new Vasil feature of reference inputs coming up, this method opens the door to exciting solutions! This since you only have to provide/verify a log(n) proof to fetch a leaf to use in some other plutus script. A small disclaimer here, a dataset in one UTxO is not a concurrent solution, splitting it over multiple outputs may be desirable. Moreover, the length of the database is fixed (though you could set entries to null).
I hope you liked this in depth post! You can find an implementation of Merkle trees for plutus here (3).


text:
It is possible to run a cardano node through a external drive?
currently i'm running out of storage and just to experiment i'm thinking about to run it through an external drive. Does somenone know if it's possible? And if it is can you give some reference about how to do it?
Thank you forehand, saludos!

You just mean to have all the disk storage the node needs on an external drive? Sure that is possible. How you do it depends on which OS you are running on (eg Windows, Linux, Mac).

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Is there any way to convert any other crypto currency into ADA?
I want make a POS(Point of Sales) system for Cardano to accept payments, in which I need to convert other coins (e.g. ether) into ADA and store those ADA funds into Cardano wallet.
I want to make something like this, here is example
Changenow
coingate
please suggest me any idea related to how to exchange currencies and how to do it

If you want to exchange non-ADA on the fly for ADA then you will need to use an exchange. Take a look at Minswap or Sundaeswap etc as they might have APIs that you can use.
DCSpark are also looking to offer EVM related services (named Milkomeda) but I'm not sure how far along they are.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How does Cardano technically handle reorgs?
In bitcoin, a longer chain will cause a reorg if it's not the "main-chain", where some blocks' side-effects will be reverted, and others in another branch will be processed and become part of the main-chain. I can't find any resources on how Cardano does that and whether it's done in the same way.
So my question is, how does Cardano handle reorgs? Is it exactly like Bitcoin, where it stores all orphans and decides where to go based on the longest chain rule? Or is it like Polkadot/Substrate, where it just stores all block candidates in memory and drops them once blocks are finalized? Or is it something else?

When electing a chain at a fork, the other chain will be discarded.
The chain selection is using the order below:

chain length
if 2 chains have a new block with same slot, then prefer block minted ourselves - if applicable
if 2 chains have latest block by same producer, compare Operational certificate (the one that is higher than last minted block on chain from producer, post Vasil - by exactly 1)
Descending order of leader VRF hash

Note that the max chain depth for fork resolution is limited and specified via genesis

Thank you for the answer. Two questions come to mind. 1. Does Cardano have a name for this process that I can find in the source code? The word reorg doesn't appear in the source code. And 2. Where do the competing chains reside before "finalizing" one of them, in memory or on disk, in the key-value store?

I believe the term you're looking for is "chain selection" , you can find the logic used for Praos chain selection at tip here. The chain resolution would occur at tip (first instance of where node sees a fork), and accordingly be committed to disk. If it encounters a block that requires a rollback of chain node was on, it can do so. Since there is a protocol limit for chain depth, the immutable DB vs volatile can be precisely maintained


text:
Benefits and use cases of Sidechains
From my understanding, a sidechain is just another blockchain with smart contract language capabilities which can speak to the parent chain. And both chains speak to each other using smart contracts for the purpose of knowing what and when to mint and burn assets.
Firstly, what are some current technologies or processes that sidechains are a more efficient alternative to? What are some possible benefits of using a sidechain?
Secondly, what are the steps required to build a sidechain which would work with Cardano? For example if I wanted to build a replica of the EVM sidechain being developed by IOG, what  are all the different components I need to build?
Thanks,
Myles

To first part: sidechains can be useful for scalability (de-congesting a primary chain, with cheaper and fast transactions).  Other uses include experimental use or specialisation for particular applications or use cases


text:
cardano node syncing stucked at some point
I am using cardano node version 1.35.3 but its syncing stopped at this point.
[otari457:cardano.node.ChainDB:Error:36] [2022-08-22 13:34:49.40 UTC] Invalid block 708745ea94515b679223a5514e6e6dba068208e5b79780134206f74e1e79e727 at slot 63419637: ExtValidationErrorLedger (HardForkLedgerErrorFromEra S (S (S (S (S (Z (WrapLedgerErr {unwrapLedgerErr = BBodyError (BlockTransitionError [ShelleyInAlonzoPredFail (LedgersFailure (LedgerFailure (UtxowFailure (MalformedScriptWitnesses (fromList [ScriptHash "eee7bfb25cfbbbcd31a1d5d648429ff919430ee5d06d8d056e48d605"])))))])})))))))
[otari457:cardano.node.ChainDB:Info:36] [2022-08-22 13:34:49.40 UTC] Valid candidate ce9c9431882310df559099e2bfa3e6eb31c95606d83ffc05568df7f863d4db60 at slot 63419598

Have you tried stopping and restarting it?

yes.But it's not working. I am getting this when I run cardano-node --version, cardano-cli 1.35.3 - linux-x86_64 - ghc-8.10 git rev 950c4e222086fed5ca53564e642434ce9307b0b9 It's latest version.

You are running this node on the legacy testnet (network magic 1097911063), It's better to connect to one of the new testnet (1). You can for example connect to the pre-production testnet.
The block you described is only valid for node 1.35.2, other nodes will not accept. There was a bug.

Didn't get it what exactly need to do?

What tutorial did you use to launch the node?

Thank you @fermat . btw, the network magic set to 9

I changed cardano-node to version 1.35.2, and it's working now.

Just so you know and how it sounds is you are running on testnet. The latest supported version of cardano-node  that works is 1.35.2 for testnet. 1.35.3 will crash due to a bad block

This is not right. Actually the version 1.35.3 is working in Mainnet and it is ready for the hard fork in September 22.

@FalconStakepool we are talking about the testnet network. You are correct for preview, pre-prod and mainnet network 1.35.3 works fine.

You are right, sorry about that.


text:
How to get PublicKey from PrivateKey
I want to retrieve the public key from a private key created via a mnemonic key.
const { mnemonicToEntropy } = require('bip39');
const CardanoWasm = require('@emurgo/cardano-serialization-lib-nodejs')

const { WalletServer, Seed } = require("cardano-wallet-js");

const entropy = mnemonicToEntropy(
  [ "test", "walk", "nut", "penalty", "hip", "pave", "soap", "entry", "language", "right", "filter", "choice" ].join(' ')
);

const rootKey = CardanoWasm.Bip32PrivateKey.from_bip39_entropy(
    Buffer.from(entropy, 'hex'),
    Buffer.from(''),
  );

let privateKey = Seed.deriveKey(rootKey, ['1852H','1815H','0H','0','0']).to_raw_key();
console.log(privateKey.to_bech32());

How do I get a proper public key format like "addr..."?

You can follow the instructions here to derive different addresses from the rootKey you've already created:
https://github.com/Emurgo/cardano-serialization-lib/blob/master/doc/getting-started/generating-keys.md#use-in-addresses
You'll probably want to 1) create the accountKey + utxoPubKey + stakeKey, then 2) create the baseAddress, like so:
  const CardanoWasm = require("@emurgo/cardano-serialization-lib-nodejs");

  const harden = (num: number): number => {
    return 0x80000000 + num;
  }

  const rootKey = CardanoWasm.Bip32PrivateKey.generate_ed25519_bip32();

  // Start from here

  const accountKey = rootKey
    .derive(harden(1852)) // purpose
    .derive(harden(1815)) // coin type
    .derive(harden(0)); // account #0

  const utxoPubKey = accountKey
    .derive(0) // external
    .derive(0)
    .to_public();

  const stakeKey = accountKey
    .derive(2) // chimeric
    .derive(0)
    .to_public();

  // base address with staking key
  const baseAddress = CardanoWasm.BaseAddress.new(
    CardanoWasm.NetworkInfo.mainnet().network_id(),
    CardanoWasm.StakeCredential.from_keyhash(utxoPubKey.to_raw_key().hash()),
    CardanoWasm.StakeCredential.from_keyhash(stakeKey.to_raw_key().hash()),
  );

  const address = baseAddress.to_address();

  console.log(address.to_bech32()) // "addr..."

Edit:
Since you seem to be using your own cardano-wallet backend with this cardano-wallet-js client, the above is not needed. You create your wallet from the seed phrase via walletServer.createOrRestoreShelleyWallet() (see here) and list wallets (and their IDs) via walletServer.wallets(). The wallet id here is just something that this particular tool creates to let you distinguish between multiple wallets that you create with it; not something required by the network or derived from the private key. To get the addresses of a wallet you can use getAddresses() or getUnusedAddresses(), see https://github.com/tango-crypto/cardano-wallet-js#wallet-addresses

Thank you! Is it possible to retrieve the wallet id via private key? I'd like to send a transaction but it seems not possible without using the wallet id :/

Edited the answer to include the info on the wallet id. Basically there's many ways to create wallets & transactions and submit them to the network. When using the  cardano-wallet backend, you don't need to think about how to derive payment addresses from private keys and that sort. The wallet id is just a wallet references created by this particular tool for convenience.

Yes, but I cannot create a wallet with only one address in it. What I want is for each user needs to have a unique identifier like a private key but I cannot send transactions by using only the PK, a wallet id is required in each doc that I see.

Not exactly sure what you mean, but using cardano-wallet, why not give every user a wallet with a "wallet id"? You shouldn't need to touch any private keys. It handles those for you.

Regarding your first point: Every wallet can have multiple addresses, but you don't technically have to use them, if you don't want to. You can also use a single address per wallet.


text:
What are the valid NETWORK values for docker node images?
I can find no documentation, nor even the original docker image file, for the cardano node docker images. We are trying to direct our node to connect to pre-production. Presumably there is a value for the NETWORK environment variable which corresponds to that.
Does anyone know where to fine an enumeration of all valid values for the NETWORK var?
For reference, I'm referring to this image: https://hub.docker.com/r/inputoutput/cardano-node

In my experience IOG's bash scripts, used for running cardano-node, are poorly documented and have poor error handling. I suggest running cardano-node directly with the relevant config files:
/usr/local/bin/cardano-node run --config $CARDANO_CONFIG --topology $CARDANO_TOPOLOGY --database-path $CARDANO_DATABASE_PATH --socket-path $CARDANO_NODE_SOCKET_PATH --host-addr 0.0.0.0 --port 3001

The relevant config files can be found here: https://book.world.dev.cardano.org/environments.html
Of course you would have to change the entrypoint of the docker image. For that I suggest creating a new Dockerfile that wraps inputoutput/cardano-node:latest:
# syntax=docker/dockerfile:1
FROM inputoutput/cardano-node:latest

RUN mkdir -p /data/preprod
RUN mkdir -p /ipc

COPY ./config.json /data/preprod/config.json
COPY ./topology.json /data/preprod/topology.json
COPY ./byron-genesis.json /data/preprod/byron-genesis.json
COPY ./shelley-genesis.json /data/preprod/shelley-genesis.json
COPY ./alonzo-genesis.json /data/preprod/alonzo-genesis.json

COPY ./entrypoint /usr/local/bin/entrypoint
RUN chmod +x /usr/local/bin/entrypoint
ENTRYPOINT ["bash", "/usr/local/bin/entrypoint"]

The entrypoint script should contain the first command I mentioned:
#!/bin/bash

export CARDANO_CONFIG=/data/preprod/config.json
export CARDANO_TOPOLOGY=/data/preprod/topology.json
export CARDANO_DATABASE_PATH=/data/preprod/db
export CARDANO_NODE_SOCKET_PATH=/ipc/node.socket

exec /usr/local/bin/cardano-node run --config $CARDANO_CONFIG --topology $CARDANO_TOPOLOGY --database-path $CARDANO_DATABASE_PATH --socket-path $CARDANO_NODE_SOCKET_PATH --host-addr 0.0.0.0 --port 3001

Finally build your image and run it:
docker build -t cardano-preprodnet .
docker run -d -v cardano-node-data:/data cardano-preprodnet

A github repo that does precisely what I described above can be found here: https://github.com/Hyperion-BT/cardano-node-wrappers (disclaimer: I am the creator)

I was able to verify and having using docker image cardano-node:1.35.3-configs you can use environment variable NETWORK=prepord
docker run -e NETWORK=preprod inputoutput/cardano-node:1.35.3-configs

I have seen invocations of this this -new docker image with environment variable NETWORK=preprod set in the #spo-public-testnet channel on IOGs discord. However I do not have any more documentation and would like to know more about it as well.

Check this out:
https://forum.cardano.org/t/how-i-run-cardano-node-in-docker/108328
That should give you idea how to run official IOHK docker images


text:
Connect docker cardano-node 1.35.3 to pre-production testnet
The dockerized version of cardano-node version 1.35.3 connects to the mainnet by default. We wish to connect the node to the new pre-production or preview testnets. It isn't made clear in any documentation how to accomplish this.
For reference, I'm referring to this image: https://hub.docker.com/r/inputoutput/cardano-node
This is related to What are the valid NETWORK values for docker node images?

A solution, involving setting up a new docker image, can be found here: https://cardano.stackexchange.com/a/8940/7460

Here's how I solved it:
Get the config files from here: https://book.world.dev.cardano.org/environments/preprod/
Place the config files in $PWD/config/docker_configs/preprod where $PWD is the dir containing your compose.
docker-compose.yml
  cardano-node-testnet:
    image: inputoutput/cardano-node:1.35.3
    container_name: cardano_node_testnet
    volumes:
      - node-testnet-db:/data/db
      - node-ipc:/ipc
      - $PWD/config/docker_configs/preprod:/config
    command:
      - run
      - --config /config/config.json
      - --topology /config/topology.json
      - --database-path /data/db
      - --socket-path /ipc/node.socket
    restart: on-failure
    healthcheck:
      # Ping the EKG port to see if it responds.
      # Assuming if EKG isn't up then the rest of cardano-node isn't either.
      test: [ "CMD-SHELL", "curl -f 127.0.0.1:12788 || exit 1" ]
      interval: 60s
      timeout: 10s
      retries: 5
    logging:
      driver: "json-file"
      options:
        compress: "true"
        max-file: "10"
        max-size: "50m"

Thanks to adamuso on the iohk discord for the help.

Please check my post in cardano forum here:
https://forum.cardano.org/t/relay-node-in-docker/102416/2?u=os11k
Basically you need to run it in docker compose, config files should be under ./node-config on host server. Keep in mind in my example I use testnet-config.json & testnet-topology.json as file names, you can change them in Dockerfile.
And you need to have Dockerfile in same dir where is docker-compose.yml
FROM inputoutput/cardano-node:1.35.3
ENV CARDANO_NODE_SOCKET_PATH=/ipc/node.socket
ENTRYPOINT ["/usr/local/bin/cardano-node", "run", "+RTS", "-N", "-A16m", "-qg", "-qb", "-RTS", "--topology", "/config/testnet-topology.json", "--database-path", "/data/db", "--socket-path", "/ipc/node.socket", "--host-addr", "0.0.0.0", "--port", "6001", "--config", "/config/testnet-config.json" ]

That should make it.


text:
Configuring Nix Cardano Node for pre-production / preview
The build instructions using nix for the cardano node are well documented, however they currently lack an option to build pre-production and preview testnet.
Does anyone know which config I could adjust to make them build these networks ?
I do know I could change configs under '/nix/store/...', but I don't think this is the right way.

You can go to Cardano Testnet - Getting Started. It will explain how to set up your node for Preview and Pre-Production Testnet, complete with the configuration files.
There are also different value for each networks --testnet-magic INTEGER:

Vasil devnet : 9
Preview : 2
Pre-production : 1

This is the general steps from the docs:

Build the latest cardano-node tag (currently 1.35.3)
Download the configuration file specifically made for each Preview or Pre-Production testnet
Run your node


text:
Confusion about the time until true immutability
The security parameter k is set to 2160 blocks. The code comment describing this genesis parameter makes it crystal clear it defines the maximum number of blocks the chain could potentially roll back. 2160 blocks equals 43,200 slots, or 12 hours.
Compare

The Ouroboros security parameters, aka k. This is the maximum number of blocks the node would ever be prepared to roll back by.
Clients of the node following the chain should be prepared to handle the node switching forks up to this long.
Source: https://github.com/input-output-hk/cardano-node/blob/master/cardano-api/src/Cardano/Api/GenesisParameters.hs#L55-L61

and the description in CIP#9

After how many blocks is the blockchain considered to be final, and thus can no longer be rolled back (i.e. what is the maximum allowable length of any chain fork).
Source: https://cips.cardano.org/cips/cip9/

to this article in the official docs

A transaction becomes immutable as soon as its depth is greater than 3k/f slots (that is, 129600 slots on current mainnet, or 36 hours).
Source: https://docs.cardano.org/learn/chain-confirmation-versus-transaction-confirmation

Can someone please explain

what is the source for the docs to come up with this formula 3k/f?
which statement is correct (12h or 36h), and why?

The documentation site (docs.cardano.org) is wrong, the one in genesis is correct.
Unfortunately I find it painful that ones maintaining/merging documents are not hands on - so depend on others to provide correctness of data. Hopefully you can address it via PR

Thanks for the answer. I do believe you, but can you also explain why the supposedly wrong docs came up with this formula in the first place? I mean who would just make up a formula from thin air.

I can see this false statements were already brought in with the first commit https://github.com/input-output-hk/cardano-documentation/commit/116b63b5e2c390f759c000b156fac965ae8d6d08#diff-e69cde811ecada31684af7d3800dcbf7f92445a7723c818268bcf557ad266513
I can also see you've submitted some changes to the file yourself. I presume you didn't know either at the time.

I asked them to correct it before (earlier version they confused k with nOpt), the updated version is no better either, as it uses false statements. In the end , problem remains the ones maintaining docs want to go back to their IO team for confirmations and come back with half corrections, I gave up on the mentioned site, better for community to focus on preparing documentations on developers.cardano.org instead of 1 org vertical structure


text:
Can't sign data with Nami Wallet
I'm facing a problem when I try to sign data with Nami Wallet API.
Here is the code snippet:
let namiAPI = await window.cardano.nami.enable();
let addr = await namiAPI.getUsedAddresses();
let payload = "48656C6C6F20576F726C6421"; //hex of "Hello World!"
let signed = await namiAPI.signData(addr.get(0), payload);

I get the following error:
{
    "code": 4,
    "info": "If a wallet enforces data format requirements, this error signifies that the data did not conform to valid formats."
}

What could be the problem? Am I encoding the payload wrong?

That payload looks good, just the address seems invalid. Probably need to access the array via addr[0] instead of addr.get(0), try this:
let namiAPI = await window.cardano.nami.enable();
let addr = await namiAPI.getUsedAddresses();
let payload = "48656C6C6F20576F726C6421"; //hex of "Hello World!"
let signed = await namiAPI.signData(addr[0], payload);


text:
Any up to date Plutus tutorials for how to use the Emulator Trace?
I've recently updated my plutus-starter based app to the latest version, and it now references plutus-apps v0.1.0, and there are a lot of changes compared to what I started with in January.
It seems the data types and functions for using wallets and setting up the Emulator has changed a lot.
Does anyone have a link for a good tutorial on how to run the Emulator to test your contracts out?
TIA.

You can refer to the plutus-contract tests which use the Emulator Trace
https://github.com/input-output-hk/plutus-apps/tree/main/plutus-contract/test/Spec

ok, Thanks. I'm going to look at some files like plutus-apps/doc/plutus/tutorials/Auction.hs, to try to figure out how this testing/emulator set up all works.


text:
How to switch from Legacy Testnet into Preview / Pre Production Testnet?
I have previously installed node 1.33.0, and now I've upgraded my node to 1.35.0. I already have a 'db' folder when I'm using 1.33.0. If I want to switch to Preview / Pre Production configuration and environment, should I create a separate 'db' folder and download the full blockchain from the beginning, or can I use my previous 'db' folder from the Legacy Testnet? Will it cause any conflict?

First, you need to upgrade to 1.35.3 for Preview or Preprod.
You will need the new configuration files for Preview or Preprod (https://book.world.dev.cardano.org/environments.html), and you need to delete the db folder and sync from scratch (which is very fast now, as the blockchains are small).

Thank you. I have follow-up questions:

Are there any binary or executables that are ready to download for MacOS, so I don't have to build using Nix?

What is the difference between Preview and Preprod? I read it here that the Preprod is still on Alonzo and not Plutus V2 updated

I don't know if you can find the binaries for MacOS.
The difference in explained in the link I gave you in the answer. And correct, preview is forked, preprod still in Alonzo.


text:
Connect cardano-wallet to pre-production testnet
We use the prescribed docker compose from iohk. Here is the cardano-wallet excerpt:
cardano-wallet:
    image: inputoutput/cardano-wallet:2022.8.16
    container_name: cardano_wallet
    volumes:
      - wallet-testnet-db:/wallet-db
      - node-ipc:/ipc
    ports:
      - 8091:8090
    entrypoint: []
    command: bash -c "
        ([[ $$NETWORK == \"mainnet\" ]] && $$CMD --mainnet) ||
        ($$CMD --testnet /config/$$NETWORK/genesis-byron.json)
      "
    environment:
      CMD: "cardano-wallet serve --node-socket /ipc/node.socket --database /wallet-db --listen-address 0.0.0.0"
      NETWORK: "testnet"
    restart: on-failure

Now that we are connecting our node to pre-production, we are getting the following error:
cardano_wallet    | cardano-wallet: ExceptionInLinkedThread (ThreadId 17) (HandshakeError (Refused NodeToClientV_13 "version data mismatch: NodeToClientVersionData {networkMagic = NetworkMagic {unNetworkMagic = 1}} /= NodeToClientVersionData {networkMagic = NetworkMagic {unNetworkMagic = 1097911063}}"))

This makes sense to me. It looks like the wallet is trying to connect to the old testnet using the old network magic 1097911063. The problem is that it isn't clear how to get it to connect to preprod instead.

The problem here was that iohk updated the 2022.8.16 image tag with new configurations but without creating a new tag. If someone gets the latest version of that image then using NETWORK=preprod should work.


text:
What's the best hardware device to generate stake pool cold-keys and key rotation?
What are the best recommended hardware devices to use that are offline / cold to generate the stake pool cold-keys and key rotation?

Laptop with WIFI switched off?
Raspberry pi zero with wifi disabled? not connected to power when offline?

Why not use your Ledger hardware wallet for the stake pool cold key?
It is not possible to import your existing keys to it, you can use it only if you start a new stake pool and create a new cold key.

I didn’t even think of using a ledger, that’s an interesting idea. Do you use that?

No, because I started my stake pool before that feature became available, and importing existing cold keys is not possible. But I would probably do it now, if I started a new stake pool.

Thank you George. Would you happen to have a tutorial about how to do this? Or link? Thx!

You can find instructions here: https://github.com/vacuumlabs/cardano-hw-cli/blob/develop/docs/pool-registration.md

I use an older Intel NUC that has no network capabilities. If you use a device with WiFi or Bluetooth capabilities, I strongly suggest that you disable the WiFi card and Bluetooth in the system BIOS before installing your OS.

Either of those options are fine.  You want your cold environment to stay cold.  The hardware requirements are minimal for generating keys and signing transactions.  Of the machines you listed above, I'd go with whichever machine you are most likely to keep offline and cold.  Disabling WiFi and Bluetooth in the system BIOS, as well as a fresh OS install before key generation would be best.  Also, remember to follow offline workflows for system, node, and software updates.
I use an old laptop and keep it tucked away until I need it.

bonus points for physically removing the wifi card from your hardware

Another solution is to use a bootable USB with TailsOS installed in it.
This operating system is created to block surveillance and enanche privacy and it permits to you to block any connection at boot and have a persisten encrypted storage.
If you are interested, I created a guide on how to implement this solution.
I can give you support in case of need.


text:
What happens if I omit a datum hash in a transaction to a script address?
When using a Trezor to sign a transaction with a script address as the receiver, I get the message "The following transaction output contains a script address, but does not contain a datum.  Continue?".
If I confirm the signing of the transaction and complete sending, the transaction goes through and the balances are updated as expected.
From what I've read in various documentation, it's mentioned that a datum hash should be attached to the UTXO at the script address.  Does that mean that it is mandatory to have one in order for the script address to use the UTXO?
In my case where I did not attach a datum hash to the transaction, can the receiving script address spend the UTXO it was sent?

Currently, Cardano has two types of addresses, verification key witnessed addresses and script witnessed address. The former allows spending of value (in the form of UTxOs) from that address if the transaction that specifies the spending contains the signature of the associated signing key. The latter allows the spending of value if the script that hashes to the address validates true given three arguments of the transaction. These are, the datum, the redeemer, and the context.
Without one of these, a script cannot validate, this is because the lowest level of code on the ledger (untyped plutus core) must have these inputs to derive its return value. The reason it needs inputs, is that it is a lambda calculus. This is a functional way of doing computation, and to return anything you need to reduce the lambda functions(1). With a missing argument, you can only reduce to a certain point.
So, if a script requires a datum, but the UTxO at its address has none, it is unspendable (currently).
DISCLAIMER: Besides plutus scripts, which I mainly touched upon, there are also simple scripts (2). These are also scripts, but they do not need a datum! It is currently not possible to distinguish a plutus script address from a simple script address from solely their address. This means that your Trezor, will also flag the simple script address with that warning, though it is not needed. There is a CIP (Cardano improvement proposal) that tries to fix this by annotating each address with a script version indication (3).


text:
cardano-node: error while loading shared libraries: libsecp256k1.so.0:
I compiled cardano-node 1.35.3 on another Ubuntu box and copied over, but it seems a library is missing.
cardano-node: error while loading shared libraries: libsecp256k1.so.0: cannot open shared object file: No such file or directory

What can I do to fix this?

You need to download, compile and install libsecp256k1:
git clone https://github.com/bitcoin-core/secp256k1
cd secp256k1
git checkout ac83be33
./autogen.sh
./configure --enable-module-schnorrsig --enable-experimental
make
make check
sudo make install
sudo ldconfig

Details https://www.coincashew.com/coins/overview-ada/guide-how-to-build-a-haskell-stakepool-node/part-i-installation/installing-ghc-and-cabal

You might need to reboot after this.

Only took my second node for me to realize there is a line missing from the https://developers.cardano.org/docs/get-started/installing-cardano-node version.  The line below is missing from the docs but you can see it in sunapi386's answer
sudo ldconfig


text:
Devnet for Cardano
Is there a Devnet(single node) available for Cardano?. With other blockchains you can get instruction abt configuring Devnet, Testnet and Mainnet. With Cardano I read only about Testnet and Mainnet. Can you please let me know if devnet configuration is available?.

Running a local single-node cardano devnet is actually quite simple. But I also do not remember seeing any documentation about it.
Maybe this docker-compose.yaml from the Hydra demo and the configuration used in there will help you get started: https://github.com/input-output-hk/hydra-poc/blob/cc8f40fcd21261329ca36a3f7c03981721977631/demo/docker-compose.yaml#L4-L22
The hydra demo starts a single cardano-node given some fixed credentials, which starts in the wanted Era right away and produces blocks as the single stake pool on the network. Make sure to also check out the prepare-devnet.sh script, which needs to be executed before starting the docker container (it sets start times of the devnet, which need to be recent enough)

I had this question some time ago as well. In the node repo there is also a script that starts a local testnet. See https://cardano.stackexchange.com/questions/8836/deploy-a-local-testnet

Here you can find the different environments available with Cardano.
Documentation on how to configure them could be incomplete due to the fact that new testnets where created recently.
You can also find additional information on the developer portal


text:
Getting PubKey from bech32 address
The verification key is referred to as public. Could it be derived from the bech32 address?
e.g addr1... -> Pubkey [cborHex]

This has been answered before here

Incorrect. I do not need the pubKeyHash, rather the PubKey itself

not directly, but there are some PubKeys in metadata or Plutus datums, you can scrape the blockchain and build an incomplete dictionary

No, the public key (also verification key) cannot be derived from a bech32 address. Only the hash of the public key is encoded in the address.
The verification key is secret as long as it is not used to spend some value from one of the corresponding addresses. When such a transaction is onchain, then you can extract the public key from it (1)(2).

What is the purpose of PubKey? I thought it can be used to verify the signing key (skey). I thought PubKey itself is s type of hashing of skey

The public key is derived from the signing key, and is used to verify the authenticity of a signature. To obscure the public key onchain a hash of it is used in the addresses. A reason to use this is to have a fixed length to represent things. Both a script hash and a public key hash have the same lenght.

Where can I learn about how the verification of signing a tx is done. Say there is one untxo as input, and one signing key given. What is the algorithmic procedure that is done on utxo hash plus skey that guarantees legit signature?

Onchain you can use https://github.com/input-output-hk/plutus/blob/fd927b1b9cb3292ed3409b0d40f0dcf627e13323/plutus-tx/src/PlutusTx/Builtins.hs#L133. What is your goal?

My goal is to educate myself more about Cardano. I would like to have an understanding of high verification is done. This will widen my knowledge about the chain.

As Fermat said, the Bech32 address only contains the PubKey Hash, and therefore we can't reverse it to obtain the PubKey.
The purpose of PubKey is to act as Verify Key, that will verify the authenticity of a signed transaction with its signature
You can refer to this video by Andrew, it will explain how addresses work in Cardano
Video: Cardano Addresses

Hello, Andrew's videos are insightful. I am aware that only the hash of the PubKey could be derived from bech32. Ok, maybe an alternative answer would be how can the witness set be retrieved for a given transaction? After all, BP nodes need to verify Tx's and PubKey purpose is to be shared to validate the owners signature

I haven't found the answer to that either. My assumption is that every time we submit a Tx, we send our SignedTx and our PubKey. I assume you already know how UTxO works, so now the BP node could check the input UTxO address, and compare it with our provided PubKey. If the hash of that PubKey matched, now the PubKey is used to verify the SignedTx. The design decision for this architecture would be to reduce data stored in the blockchain, because we don't have the full PubKey stored in it, just the hash of it

Transactions on chain only have the input utxos and the recipient outputs. I can not find where on chain does the pubkey get stored and attached to a transaction neither its hash

The address IS the PubKey hash, refer to CIP-19. For example, in this transaction we can get the PubKeyHash through bech32 decoding which is addr1q85cjaunup5pjnfuup244v78ccan2mykhhm346fqcf9heqqh8l0k78a59nm52ahfkxpx5r2sucupdaqvdxfk03fqp9kqqagfvq --> 01e9897793e068194d3ce0555ab3c7c63b356c96bdf71ae920c24b7c80173fdf6f1fb42cf74576e9b1826a0d50e63816f40c699367c520096c. Take the first 56 character after 01, and you get the PubKeyHash


text:
Is IOG’s PAB going to be deprecated?
I wonder if we should consider the official PAB deprecated.

There is no information that IOG is planning to deprecate the PAB.


text:
Retrieve Witness Set from Transaction ID
Is there a tool or method to get the set of witnesses (public keys) of a transaction given the transaction ID?

If you have the Tx file, you can use $ cardano-cli transaction view --tx-body-file tx.raw to view the witness set. But, if you specifically want to extract from a given Tx ID, you can extract the witnesses' information through their input UTxO. The UTxO contains an address that is made up of a hashed public key, and from there you can list the public key hash needed for this transaction, also known as the witnesses required
Edit:
According to this thread the witness information is actually in the blockchain, but not currently possible to extract it using db-sync. Reference to this specification for proof that the blockchain indeed stored the witnesses' key


text:
Reactivate Retired Stake Pool
If I still have all the keys is it possible to reactivate a stake pool that was previously retired?

All you need is the cold key to reactivate a stake pool. The rest can be replaced. If you have all the keys and you want to reuse them, you can. But only the cold skey matters.
I assume you will need to pay attention to the counter for the operational certificate. You will need to have a bigger counter (preferably +1) for the operational certificate than the one used to mint the last block.


text:
cardano serialization lib - Multiple addresses and stake keys
I was able to generate a single address following the guide. My question is regarding stake key. Is it necessary to derive a new stake key for each new address or can you just increment .derive(n + 1) and use the same stake key?
const utxoPubKey = accountKey
  .derive(0) // external
  .derive(0)
  .to_public();

const stakeKey = accountKey
  .derive(2) // chimeric
  .derive(0)
  .to_public();

const baseAddr = CardanoWasm.BaseAddress.new(
  CardanoWasm.NetworkInfo.mainnet().network_id(),
  CardanoWasm.StakeCredential.from_keyhash(utxoPubKey.to_raw_key().hash()),
  CardanoWasm.StakeCredential.from_keyhash(stakeKey.to_raw_key().hash()),
);

Many thanks!

Every account should only use 1 stake key, and it resides within m/1852H/1815H/0H/2/0. Every new address that you generate should use the same stake key. This is so that when you're staking your wallet, it can track your balance across different payment addresses that use the same stake key.
Reference to Address Derivation documentation, under the Path Level

Thank you @dani for the explanation.
Doesn't this make it less private as you can discover the user total balance?

Yes, it is. In Daedalus wallet, they inform you about it as well. Refer to Andrew's video on how addresses work


text:
Blockfrost API and cexplorer.io about an asset does not match

When I use Blockfrost to query all the address holders of a token named NMKR,

curl  -s -H "Project_id: $BLOCKFROST_PROJECT_ID" https://cardano-mainnet.blockfrost.io/api/v0/assets/5dac8536653edc12f6f5e1045d8164b9f59998d3bdc300fc928434894e4d4b52/address

the query returns 100 addresses, with the top holders as follows:

But when I use https://cexplorer.io/asset/asset1lgultx63fukjlhsncmwp235pcnh4fh988phh7f/owner#data

then the top addresses are
top_addrs = [
    "addr1vywkezkwgf8e5wprf4nhm266rww8vq2papxpqgns3qrpwcg7vmd7g",
    "addr1qy7wtzzttymfst2umscr6m9xxscfttk0256z85qexf0v8hzx0a8wukmahzq0vn2nqrhgeym0ue2wnufv8nr9ucljtn6s9vtk4h",
    "addr1qy4uaynggpakhe26lgc0vymmdgddrk3uhvgdddlfs8vt4846ghwzul6wjv2r6lkz3pgapen49jmtmls00sn36aacc3csdf0zu6",
    "addr1qyvm697fy60ulksyhjzyz7tmqjt3h8u6s99u7vcqzacfq6z3eekl4qcr5k69u4h02j2wau7js8zgcmp0h5nql3jrdy9qvy4e8t",
    "addr1q98qjgkvv6ul6p5tlxvq9zxklnj87y0lf4s0lta4km4s0scktx0qwk39jnq9a3krt20xa07fgkpf23q4wl3sqcgmrwps79n8u9",
]

These addresses are not included in the 100 addresses above, the amount are also different.
Can you please explain why?
Thanks a lot.

Blockfrost doesn't return the results ordered by quantity (but by time, see here), so you'd have to page through the results to see more than those 100 addresses and find the ones you're looking for. When you find them, they will eventually have the same quantities.
For example, you'll find your top address from cexplorer here on page 2:
https://cardano-mainnet.blockfrost.io/api/v0/assets/5dac8536653edc12f6f5e1045d8164b9f59998d3bdc300fc928434894e4d4b52/addresses?count=100&order=desc&page=2

I see, thank you very much.


text:
Can I send funds from Shelley Wallet to Byron Wallet?
I've got a very simple question, is it possible to transfer funds from Shelly to Byron or Byron to Shelley Wallets? If it's possible, do I need to consider anything else different than sending as usual between two Shelley Wallets?

No, transactions where the destination address is a Byron era address are no longer valid. I think you can send funds in Byron era addresses to Shelley addresses.
If you still have a Byron era wallet I highly recommend that you upgrade it to Shelley sooner rather than later. At least in the Daedalus wallet, this is trivial.

Turns out that the answer I gave above is actually incorrect. The following is from my IOG colleague Sam Leathers.
Byron addresses are just as valid as Shelley in the ledger, although have a slightly larger minutxo because of their size. A number of large exchanges still only use Byron addresses. Its probably not a good idea but it is valid.

Yes, you can send funds to Byron address from Shelley address and vice-versa. You can spend ADA and native assets like that. Nothing special is required.


text:
Understanding the serialization and the deployment of a custom untyped plutus core implementation
I have found this open source project that aims to create a typescript library to write smart contracts.
I had a look at the code but was not able to understand a couple of main pieces useful to understand the whole picture.
Of course the author is following the Plutus Core Specificiation in order to create the library, but to me is not clear where the actual serialization happen.
Also, when the serialization is done, how will be possible to push it to the computational layer of the blockchain? Should we crate a particular transaction containing the obtained binary code?
Thanks

Searching in the existing folders I ended up finding the UPLCEncoder implementation.
in particular, the class exposes a compile method that has the following signature:
compile( program: UPLCProgram ): BitStream

so it is something that given a UPLCProgram instance returns a BitStream; the implementation of the BitStream class suggest it is a wrapper ona bigint js primitive value used to store the compiled program.
back to the compile method; the library already supports hoisting; so the first part of the method is about inlining hoisted terms;
the actual compilation is forwarded to the encodeTerm method as we can see from
result.append(
    this.encodeTerm(
        progrTerm
    )
);

the implementation of encodeTerm is just an intermediate step to choose the encoding to use based on the actual UPLCTerm instance passed.
once encodeTerm understands the type of the terms calls the specific encoding function that translates 1:1 the UPLCTerm to binary (using BitStream) and calls again encodeTerm (mutually recursive) when necessary as in the case of Application encoding
const result = Application.UPLCTag;
this._ctx.incrementLengthBy( result.length );

result.append(
    this.encodeTerm( app.funcTerm )
);

result.append(
    this.encodeTerm( app.argTerm )
);

once compile returns the BitStream currently the solution is to use the toBuffer method to get a Buffer from it and convert it to the serialized hexadecimal string that can be submitted in a transaction, just like any other smart contract.
it has to be said that the project is quite new so I'm sure there will be a more direct way to obtain the hexadecimal string.


text:
'No Corresponding Policy Script' Error when Script Was Provided
Following the Mintin NFTs IOHK tutorial I end up with the following error when crafting the transaction.
Command failed: transaction build  Error: The "--mint" flag specifies an asset with a policy Id, but no corresponding monetary policy script has been provided as a witness (via the "--mint-script-file" flag). The policy Id in question is: ..9570b

I don't understand the error because I am giving the script file with the flag mentioned.
cardano-cli transaction build \
--testnet-magic 1 \
--tx-in ...e6f70#0 \
--tx-out addr_test1...s8qjk+2198569+"1 ...9570b.4d7946697273744e4654" \
--change-address addr_test1vrhwzwj5plmracdydsr57k7putcuxfzktffc2v4hgm7kc8gfs8qjk \
--mint="1 ...9570b.4d7946697273744e4654" \
--mint-script-file policy.script \
--metadata-json-file metadata.json \
--witness-override 2 \
--out-file tx.raw

And here is the policy.script that has the hash of the policy verification key policy.vkey.
{
  "type": "all",
  "scripts":
  [
    {
      "type": "before",
      "slot": 6378920
    },
    {
      "type": "sig",
      "keyHash": "...33060c"
    }
  ]
}

I would like to have a better idea of what can be wrong as the error is not helping in understanding what has gone wrong.

This might be too late.
Have you checked that your policyID is the same as "...9570b"?
Assuming you are following the docs and are in the nft folder you can run echo $(cat policy/policyID)
Otherwise, if you are following the docs to a T and you are not missing any step I would recreate what is written on the docs.
First I would add the era => --babbage-era \
Then if you are following the docs, perhaps the script is in a different folder.
The docs add --invalid-hereafter $slotnumber \ and witness is a WORD, therefore, needs to be written as a string => --witness-override '2' \


text:
Is it MuesliSwap the only DEX with an API?
I'd like to build a backend that brings data from all Cardano DEXes.
I have been exploring this link: https://docs.muesliswap.com/cardano/api/api-v1
Is it the only DEX that provides an API? I didn't find any information on MinSwap, SundaeSwap or Wingriders.

Minswap uses a GraphQL endpoint that you can find here:

https://monorepo-mainnet-prod.minswap.org/graphql/

Example:
curl --request POST \
  --url https://monorepo-mainnet-prod.minswap.org/graphql/ \
  --header 'Content-Type: application/json' \
  --data '{"query":"query TVLSeries {  tvlSeries {    time    tvl  }}\n\n","operationName":"TVLSeries"}'

They also have an adapter to query their data using Blockfrost:

https://github.com/minswap/blockfrost-adapter

SundaeSwap has an API located at:

https://stats.sundaeswap.finance/api/

Example:
curl --request GET \
  --url https://stats.sundaeswap.finance/api/ticks/0029cb7c88c7567b63d1a512c0ed626aa169688ec980730c0473b913.70202d01/2022/09/02

Both of them don't seem to have public documentation, so you can either ask the team directly or try to find the endpoints you need.
Hope this helps!


text:
What are the protocol magic values for the preview and preprod test networks?
The cardano testnet has a protocol/testnet magic value of 1097911063.
Where do I find this value for the preprod and preview test networks?

You can check the byron or shelley genesis files for protocolMagic or networkMagic respectively.
Genesis files for each network can be found here: https://book.world.dev.cardano.org/environments.html

networkMagic from the Shelley genesis files: Preview: 2, Preprod: 1


text:
What do i pass in as the parameter to create a new Ed25519KeyHash using cardano-multiplatform-lib
I am using Dc Sparks multi-platform-lib to build my transaction.I want to add a required signer in my transaction. There is a add_required_signer method in the TransactionBuilder class and it takes in a parameter of type Ed25519KeyHash. Right now I am creating a new Ed25519KeyHash like this
const walletConnection = await window.cardano.nami.enable();
const raw = await walletConnection.getChangeAddress();
const changeAddress = WASM.Address.from_bytes(
  Buffer.from(raw, 'hex')
).to_bech32();
let signer = WASM.Ed25519KeyHash.from_bech32(changeAddress);

This is the error that it returns.
Deserialization failed in Ed25519KeyHash because: Invalid cbor: expected tuple 'hash length' of length 28 but got length Len(57).

What is the correct value I need to pass to create a new Ed25519KeyHash


text:
How can I create a token that shows 6 decimals places in Eternl?
I have created my own token and I have added a Cardano Token Registry specifying that the token has 6 decimals places. My entry looks exactly like the Minswap's token entry, but the difference is that, when I want to send a transaction, I don't have the possibility to add decimal places, like I do have on the Minswap token.
Is there anything else I should do so my token shows like this:

Not sure if Eternl has this implemented, but there is a proposal that adds this token information to the metadata of the minting transaction:
https://github.com/cardano-foundation/CIPs/blob/1d9fbd0e29f07b931bf1524c7aed6635d478cd75/CIP-0035/CIP-0035.md
Minswap doesn't follow it, but Sundae does. Here's an example under Label 20:
https://cardanoscan.io/transaction/d74798c4a1e453fbc6ba4fbb1d785e0534fb8531fd1bc054ceff5b086240d3b5?tab=metadata
Probably worth a try.
Also, if your token is not correctly displayed in Eternl, you can click the "update" button (marked in red below), to re-fetch the data of your token from the Cardano Token Registry:

I tried also with that but it doesn't work. The problem is only in Eternl, in Nami and in Cardanoscan I can visualise the right amount of decimal places.

in discord it is suggested to "press the little update icon button to fetch the new registry data". Couldn't try it myself though

Did you register your token at CFtoken registry ? You can specify decimals as part of JSON you register on that repo.

Yes, I did, my entry looks exactly like the Minswap entry.

Any other suggestion? Because I still have this issue. The problem appears to be only with Eternl, in Nami it works fine.


text:
ScriptWitnessNotValidatingUTXOW while trying to mint NFT in preprod testnet
minting script
    "type": "all",
    "scripts":
    [
        {
            "type": "after",
            "slot": 155761
        },
        {
            "type": "sig",
            "keyHash": "e9ce8633aef95b632bfbffc12a83cc4c589132c46cd03f8dae146ec2"
        }

    ]
}

metadata-json-file
    "721": {
        "ca8fc6bf8d698d5752e6c700c8a5818c2abe5a17877121ae99604e24": {
            "cat": {
                "name": "Nikki",
                "image": ["ipfs://QmQQqHaitxGkzNTRCSxJxTU5JaVvSoGGxocBcU246BZA7M"],
                "mediaType": "image/png",
                "description": "remember when?",
                "files": [
                    {
                        "mediaType": "image/png",
                        "src": ["ipfs://QmQQqHaitxGkzNTRCSxJxTU5JaVvSoGGxocBcU246BZA7M"]
                    },
                    {
                        "mediaType": "image/png",
                        "src": ["ipfs://QmYCbn5Nj3Xq28QwDkerMBAXsLBDa26f1k8jruuKn5gzXn"]
                    }

                ],
                "type": "Nadan",
                "color": "white and brown"
            }
        }
    }
}

cardano-cli query tip --testnet-magic 1
{
    "block": 153845,
    "epoch": 19,
    "era": "Alonzo",
    "hash": "789909e77ba308c069b0e09809a6ec7508da0d2c0c474565caed2688afe3618e",
    "slot": 6674546,
    "syncProgress": "100.00"
}

command line variables
POLICYID=ca8fc6bf8d698d5752e6c700c8a5818c2abe5a17877121ae99604e24
TXIN="02a037b9649eb62f17549bf33114763568b59a4be20beba6132f7b996a0825e2#0"
TOKENNAME1="6e696b6b69"
POLICYSCRIPT="ppbl-nft-2.script"
MINTER=addr_test1vr5uap3n4mu4kcetl0luz25re3x93yfjc3kdq0ud4c2xassvq0wsd
METADATA_JSON_FILE="mynft.json"
RECIEVER=addr_test1qzdquurtx940tpyfgt7pu2h8zgrgfepf7quwcqqh3kmacd83z2naq8a2cltaqyxexml30wh77uyu3sll7feyp2nzqgnqfdpnsa

// transaction cardano-cli transaction build \ --alonzo-era \ --testnet-magic 1 \ --tx-in $TXIN \ --tx-out $RECIEVER+1500000+"1 $POLICYID.$TOKENNAME" \ --change-address $MINTER \ --mint "1 $POLICYID.$TOKENNAME" \ --minting-script-file ppbl-nft-2.script \ --metadata-json-file mynft.json \ --protocol-params-file protocol.json \ --out-file nft.raw
//transaction sign
cardano-cli transaction sign \
--signing-key-file payment.skey \
--testnet-magic 1 \
--tx-body-file nft.raw \
--out-file mint-nft.signed

//submit transaction
cardano-cli transaction submit \
--tx-file mint-nft.signed \
--testnet-magic 1

ERROR
Command failed: transaction submit  Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraAlonzo (ApplyTxError [UtxowFailure (WrappedShelleyEraFailure (ScriptWitnessNotValidatingUTXOW (fromList [ScriptHash "c867c502e249d681b35a8df2e3df5e58ec2c16d3df445429484a1793"])))])

You're missing the --invalid-before flag when building the transaction. It sets the lower bound of the transaction's validity interval, which is required for the script to determine whether the interval range is greater than slot 155761. You must use a slot that is lower than the current slot.

You are using,
{
    "type": "after",
    "slot": 155761
}

while the current slot on preprod is ~154042. This policy allows using it only after slot 155761, for more info see (1). Also make sure that,
cardano-cli address key-hash --payment-verification-key-file payment.skey

is equal to e9ce8633aef95b632bfbffc12a83cc4c589132c46cd03f8dae146ec2.

i changes the script ``` {
"type": "all",
"scripts":
[
{
"type": "after",
"slot": 6702243
},
{
"type": "sig",
"keyHash": "e9ce8633aef95b632bfbffc12a83cc4c589132c46cd03f8dae146ec2"
}
]

}``` and key hash is also the same still same error

Hmm, that's weird, I also think I had the slot of preprod wrong (your query is correct).

Can you use the --invalid-after to make the transaction valid even if it is send before the after slot?

--alonzo-era \
--testnet-magic 1 \
--tx-in $TXIN \
--tx-out $RECIEVER+1500000+"1 $POLICYID.$TOKENNAME" \
--change-address $MINTER \
--mint "1 $POLICYID.$TOKENNAME" \
--minting-script-file ppbl-nft-2.script \
--invalid-hereafter 6753799 \
--metadata-json-file mynft.json \
--protocol-params-file protocol.json \
--out-file nft.raw```

still same error


text:
Where does Cardano Wallet stores created wallets in the node?
I'm running the Cardano node and Cardano wallet in the same EC2 instance. I did create a couple of wallets, however, I couldn't figure out where and how it stores created wallets in the node. I'd appreciate it if someone could tell me the path that I need to look for.

When you start cardano-wallet you specify the wallet-db folder on the command line, that DB is where your private keys are saved (private key is encrypted using your spending password before saving)

Thank you! They are stored in db-folder as you mentioned.

"Wallets" are not stored on the blockchain. You need to make a transaction to an address of your wallet. This will create a transaction, which is stored on the blockchain.

When I create a wallet via walletServer.createOrRestoreShelleyWallet I can see the wallets created in that Wallet Server by typing cardano-wallet wallets list and if I try to use that wallet in another wallet server it will not be visible because it is created in another wallet server. Therefore, I'd like to know the logic behind where the cardano-wallet wallets list command gets the created wallets in that server.

Ah seems like I misunderstood your question. Could you please provide a link to the cardano-wallet you're using?

https://developers.cardano.org/docs/get-started/cardano-wallet-js This is the source that I use WalletServer or Cardano Wallet CLI doesn't matter. I just need to know where this response gets this wallet info in the node.


text:
Native token fee
I want to implement native token in a digital wallet.
But I don't want users to have to pay a fee every time they transact with my token.
On the other hand, I want the transactions to be recorded at some point in the blockchain.
Is there a mechanism to resolve this scenario? off-chain? Do you know any project that does this or something similar?

This seems to be a good use case for Hydra, from what I know so far about it. But I cannot give you more details, you will have to search for the documentation yourself. I know about this repository: https://github.com/input-output-hk/hydra-poc - maybe it helps.

UTxOs with native tokens are larger than those without, which results in slightly larger transaction inputs and outputs. Larger transactions have higher fees, there's no getting round that onchain. You can use a short or blank token name to minimises cost to transact with your token.


text:
Is it possible to call the `mkValidator` inside the same / another `mkValidator` function for script composibility?
Supposed I have a validator below, checking only if the output value is locked by the same script.
{-# INLINEABLE mkValidator #-}
mkValidator :: TestingParam -> TestingDatum -> TestingRedeemer -> ScriptContext -> Bool
mkValidator param _ red ctx = case red of
  (MergeScript anotherParam) ->
    traceIfFalse "Script provided is incorrect" (valueLockedBy info (valHash anotherParam) == txOutValue ownInput)
  _ -> False
  where
    info :: TxInfo
    info = scriptContextTxInfo ctx

    ownInput :: TxOut
    ownInput = case findOwnInput ctx of
      Nothing -> traceError "input missing"
      Just i -> txInInfoResolved i

{-# INLINABLE typedValidator #-}
typedValidator :: TestingParam -> Scripts.TypedValidator TestingScript
typedValidator param =
  Scripts.mkTypedValidator @TestingScript
    ($$(PlutusTx.compile [||mkValidator||]) `PlutusTx.applyCode` PlutusTx.liftCode param)
    $$(PlutusTx.compile [||wrap||])
  where
    wrap = Scripts.wrapValidator @TestingDatum @TestingRedeemer

{-# INLINABLE validator #-}
validator :: TestingParam -> Validator
validator = Scripts.validatorScript . typedValidator

{-# INLINABLE valHash #-}
valHash :: TestingParam -> Ledger.ValidatorHash
valHash = Scripts.validatorHash . typedValidator

However, it then throws the error GHC Core to PLC plugin: E043:Error: Reference to a name which is not a local, a builtin, or an external INLINABLE function: Variable OtherScripts.Testing.ReferenceTesting.valHash.
Another similar issue with supplying minting policy here:
Using `curSymbol` function in Validator script
Looked at several sources and stuck with this issue for months. Can someone advises me if it is a dead end current Plutus ability?
If so, happy to see if someone is interested in drafting a CIP for this together, since allowing to use mkValidator or mkMintingPolicy script externally allows another level of scripts composibility which I think is essential for Cardano smart contract to get into mainstream. Also, this would enable scripts to be composed more secured as validator could know the identity of other scripts they are interacting with, instead of just hardcoding-supplying a validator hash externally.

In this case, when compiling your validator, compiler is trying to compute a value (which is only available after successfully compiled your validator) to complete compiling your validator, thus, it's impossible case.
Your validator is parameterized validator so with each different parameter, it's different validator with different validator hash.
If you want to get outputs of the same validator with same parameter then, that's same validator with same validator hash so there is a getContinuingOutputs function you can use or findContinuingOutputs if you are only interested in amount. Also ownHash is available for getting the validator hash within the same validator.
If it's the case that you want to check an output is locked by the same validator but with different parameter, then it's no longer same validator, it's a completely different validator with different validator hash even if the source code is the same. In this case, you probably might want to provide validator hash directly to the validator via datum or redeemer rather than providing the different parameter which is not possible to compute hash from.

I am looking for checking whether some value is correctly paid to "certain parameterized scripts" while I dont know the script address beforehand. Certainly I could remove to parameter field to use getContinuingOutputs entirely, but sometimes I also want to enable it to look at other validator and minting script as well. Any thought any workaround instead of using above code to compute?

If you want to check for "another validator" and have the functionality at hands for future cases, i would suggest you to dynamically provide the validator hash to the validator either via datum or via redeemer.

About computing script's hash (minting script or validator) on chain, i am not sure if it's possible. Let's say, that, it's possible to compute hash on chain from script's binary. How are you going to put binary in the validator? Hard code it? or again, via datum or redeemer? We now came back to the first step. If binary can be hard-coded, why not the hash of it? Same question for datum and redeemer.

Script.validatorHash can not be compiled to Plutus Core (probably for good reason, as it would've resulted in much larger on-chain scripts).
As Erik mentioned, if you only need the hash of your current validator, ownHash is the answer. But if you want to recreate the validator hash of another script on the fly, that's not possible.
A typical solution is to provide this desired validator hash as a parameter to your current script, and therefore make it "aware" of your other script.

Is there any other work-around to calculate script address onchain? Even if others have provided the validator hash in, checking on it seems necessary to prevent bad actors on exploiting the script

Generating a script hash from parameters is a somewhat resource intensive task, so it may not even be possible to achieve that within the 16KB transaction size constraint.
This depends on your contract of course, but one solution might be for your script to demand the presence of a known asset (i.e. native token) from the arbitrary script you're trying to check. This has the additional benefit of making sure that said script is in fact capable of spending its UTxOs.

I suspect that this might actually be a GHC Template Haskell (TH) staging error. My understanding is that when you use TH in a file, it must all be expanded (TH is basically a macro expansion system) on the first TH evaluation pass.
Your function valHash calls typedValidator which includes TH functionality and then you are tying to call that within mkValidator which also uses TH. That is why I think you are actually hitting a staging error due to the implicit recursion of mkValidate -> valHash -> typeValidator -> mkValidate.
The current solution (not really that nice IMO) is to provide (ie hard code) the hash itself to mkValidate. You can probably also write a test to validate that the supplied hash is the same as the actual hash provided by TH.
Update: Apparently there is an ownHash in the Plutus libs that will give you the hash of a validator inside the same validator. I have not tried it.

How about I want to calculate the script address on chain to conduct the checking? Simply submitting a validator hash in provides loophole for bad actors to exploit. Is it somewhat impossible as mentioned by @KeyanM & @Tuvshintsenguun?


text:
Workaround for Plutus Scripts that excesses the max Tx Size. Framework or examples for splitted or modular validators?
Im very interested in how you can split the validation in several validator.
There is any model or framework to follow?
Any example around?
Could somebody at least share some words of insights about it?
I come with this idea:

There is one main script, where all the Ada and Tokens are hold in different utxos with different types of Datums.

There is several other minting scripts witch produces NFTS.

OffChain, I create a data type containing all the datums and values of the inputs and outputs of the tx I want to validate. I will call this structure txInfoForValidation.

I need to send all that data to the minting validators because they can't access to the utxos located at the main validator script. They will have only this data structure that mimics the real tx I want to validate.

The minting validator checks the tx represented in txInfoForValidation and applies the business logic to approve or not the tx.

If the validation goes well, they mint an NFT.

The main validator doesn't have the business logic, but just check if a valid NFT is there. If it is present, its approves the consume of the utxos at his address.

The way for the minting validators and the main validator to communicate is trough the NFT TokenName

The NFT TokenName is based in the data structure I mentioned before. Different txs has different inputs, datums, values and outputs, and I can calculate the sha2_256 of all that structure I called txInfoForValidation. The hash of that data type is specific to that tx. The minting validators checks that the TokenName is right and then checks if it approves or not the tx that is represented there.

The main validator receives a context with inputs and outputs and OnChain recreates the data structure txInfoForValidation with all datums and values and then calculates the sha2_hash of it. If the hash calculated match an NFT present in the tx then it aproves the tx.

What do you think about this idea?
It looks in principle that it can work. Can you see any security hole here?
Anyways, I'm having some problems with this idea. It reduces Plutus Script size. I can have many minting validators with different operations in each one. But I need to compute the HASH of the data structure txInfoForValidation in the minting validators and in the main validator. This is taking too much ram and I'm getting overspent resources now.
If this idea is correct, maybe there is a better way to compute the hash of the data structure txInfoForValidation. I did it by hand, field by field, because can't use dataHash from Plutus.Script.Utils.Scripts. It requires BuiltinData and i'm struggling trying to convert my data type to BuiltinData. So I access field by field, convert each one to BuiltInByteString, concatenate all the ByteStrings with <> and calculate the hash in the end.
Thanks for your time.
Any advice will be very much appreciated.

You should checkout my open source cardano lottery repo which has code that worked on the testnet and does logic splitting across validators as well as some other optimization techniques.   That said, with Vasil coming, there will be additional ways to improve transaction size (eg. reference scripts), but you still may run into limitations with cpu and mem execution units.
https://github.com/lley154/cardano-lottery


text:
Haskell advices for optimize and reduce Plutus Script size and cpu and ram usage
I'm wondering in all the works-around to optimize and reduce the size of the scripts and resources utilization.
I'm working in a big project and I'm struggling with this runtime limitations.
I would love to be able to code the logic of any big idea or project. I believe this must be possible to do it with Cardano.
I'm not Haskell expert, so I might be falling in some beginner mistakes handling data types or code structures.
I read some articles:
1 -
https://github.com/Plutonomicon/plutonomicon/blob/main/scriptmem.md
https://plutus.readthedocs.io/en/latest/reference/writing-scripts/optimization.html?highlight=profiling
They mention:

Avoiding higher-order functions and closures.
Adding strictness on accumulators in recursive functions.
Common expression elimination.
Using error for faster failure.
Avoid monad do notation to handle pattern match failure: Can't understand this one clearly.

2 - https://github.com/Plutonomicon/plutarch-plutus
I understand that this is about coding all again, with this language that is more low level and efficient that the Plutus libraries.
3 - https://github.com/CatspersCoffee/contracts/tree/main/dex/src/Minswap
I saw in the code of Minswap, that they convert the Plutus Script with Plutonomy (https://github.com/well-typed/plutonomy)
import qualified Plutonomy
{-# INLINEABLE mkFactoryPolicy #-}
mkFactoryPolicy :: MintingPolicy
mkFactoryPolicy =
Plutonomy.optimizeUPLC $
Plutonomy.mintingPolicyToPlutus originalFactoryPolicy
But im not sure about the final code. How we can be sure that the code is reliable after it is passed trough Plutonomy.optimizeUPLC and also this is only compatible with specific older version of Plutus:
plutus-1efbb276e
plutus-4710dff2e
plutus-f680ac697 (cardano-node-1.35.1)
4 - Some configuration for the compiler, like:
https://plutus.readthedocs.io/en/latest/reference/writing-scripts/compiler-options.html?highlight=profiling
I saw that many projects use this ones in the cabal file:
ghc-options:
-Wall -fobject-code -fno-ignore-interface-pragmas -fno-omit-interface-pragmas -fno-strictness -fno-spec-constr -fno-specialise
I would appreciate any help in this matter.
If you can share your experience codding big projects and solutions you fount that will mean a lot for me.
Thank you so much.
Regards, Manu


text:
How to profile the budget usage of Plutus scripts
How to profile the budget usage of Plutus scripts
https://plutus.readthedocs.io/en/latest/howtos/profiling-scripts.html?highlight=profiling
Im struggling trying to follow the steps indicated in the howto to get the profiling of the scripts.
I added this line for the compiler, in the file where the mkValidator is:
{-# OPTIONS_GHC -fplugin-opt PlutusTx.Plugin:profile-all #-}
I compiled my code with cabal build.
Then It says you must execute:
uplc evaluate -i myscript.flat --if flat --trace-mode LogsWithBudgets -o logs
But can't find uplc anywhere.
Neither I find the output myscript.flat anywhere.
It says that "All the executables referred to here can be built from the plutus repository using cabal build"
I have the lates Plutus Apps and already built with Nix and cabal build but can't find the uplc.
It mentions after that you uses traceToStacks, another exe, to convert the results. Can't find this exe and can't execute with cabal exec traceToStacks neither.
If you did this profiling on your scripts I'll be very happy to know about it.
Thank you!!!


text:
Transaction submission times
I am building an NFT marketplace on Cardano which supports 3 wallets: Typhon, Yoroi and Nami.
I have to mint an NFT right before putiing it on sale, so I figured I need to wait for the newly minted NFT (or rather it's UTxO) to arrive at the wallet address before I build the Plutus transaction to put it on sale.
Unfortunately, sometimes wallets don't throw an error, even though the transaction submition fails. I was wondering if there is a set time which I can use as a cut-off point (as in if the UTxO didn't arrive within X amount of time after transaction was submitted - I consider the transaction as failed).

I would highly recommend against just waiting a pre-determined time and then assuming the transaction has been submitted.
Instead, you should only support wallets that do properly report an error when the transaction submission fails. You can also raise a bug against the wallets that do not do this, and say that your program cannot support them until they correctly report failed transaction submission.

I am not assuming that it succeeded, I am assuming it failed, if the UTxO has not arrived within a time limit

Ok, that makes sense, but I still recommend that you post bug reports for wallets that do not provide appropriate feedback when a tx submission fails.


text:
VSCode HLS not working for plutus project
System Info:
Ubuntu :20.04
I am trying to get VSCode HLS extension working for plutus based project but seeing below error in output.
Failed to get project GHC version: no cradle
[Info  - 3:27:24 p.m.] Connection to server got closed. Server will restart.
No 'hie.yaml' found. Try to discover the project type!
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 1.7.0.0 x86_64 ghc-9.2.2
Current directory: /home/skb/dev/emurgoProject
Operating system: linux
Arguments: ["--lsp"]
Cradle directory: /home/skb/dev/emurgoProject
Cradle type: Stack

Tool versions found on the $PATH
cabal:      3.6.2.0
stack:      2.7.5
ghc:        8.10.7```

I have nix shell evnironment via this repo: https://github.com/input-output-hk/plutus-apps
Below is what am doing:
1. Run **nix-shell** from root folder of plutus-apps repo.
2. cd (change dir) to my plutus project folder which I created based on: https://github.com/input-output-hk/plutus-starter
3. code . to open the vscode

Side note: HLS work for non plutus projects in my machine (when I am not running nix-shell).

1 -
Try running first the nix shell in a terminal then, from inside the nix shell, go to your project folder, and run: code .
Than will open you project with vcode and all the terminals and the HSL will be inside the nix shell you activated before.
Also, you will need the HLS installed inside the nix shell, for that, the best is to use ghcup inside the nix shell, to make sure all is needed is known for nix. For that run: ghcup install
You can see if there is any problem with HLS in the Output console in vcode, and in the list of outputs choose Haskell.
'
That worked for me.
2 - For the cradle message, you can add a file in you root folder:
hie.yaml
and write this inside:
cradle:
  cabal:

3 -Im editing this with something also can work.
I was having problems with some errors and everything fixed when I deleted the cache file of hie-bios:
cd $HOME/.cache/
sudo rm -R  hie-bios

Check more solutions here:
https://haskell-language-server.readthedocs.io/en/latest/troubleshooting.html
4 - I found that haskell-server-language is installed already in the nix-shell of plutus-apps
Enter in the nix-shell and write:
> whereis haskell-language-server
> haskell-language-server: /nix/store/iy740dkx9anah9j04b4g3fnd7wjws3lm-haskell-language-server-exe-haskell-language-server-1.5.1.0/bin/haskell-language-server

Then in VCODE open you settings and put that into the serverExecutablePath field:
"haskell.serverExecutablePath": "/nix/store/iy740dkx9anah9j04b4g3fnd7wjws3lm-haskell-language-server-exe-haskell-language-server-1.5.1.0/bin/haskell-language-server"


text:
Is there an equivalent of Bitcoin Script Opcodes or the EVM instruction set in Cardano
Is there some lower level code that Plutus code compiles to (akin to Solidity => EVM bytecode, or BSV sCrypt => OP_codes)?
Related (but distinct) how the state changes: https://cardano.stackexchange.com/a/7253/4968

Yes, there is a lower level code that is used onchain, it is called Untyped Plutus Core (UPLC)! When validators are written in template haskell, they get compiled via
1) GHC: Haskell -> GHC Core
2) Plutus Tx compiler: GHC Core -> Plutus IR
3) Plutus IR compiler: Plutus IR -> Typed Plutus Core
4) Type eraser: Typed Plutus Core -> Untyped Plutus Core

To learn more about UPLC have a look at this great blog.


text:
apply failed: [postgres-error] query execution failed ($.args[0].args)\\r\\nFile: '1589369664961_init/up.sql'
This is how I started docker run, but cardano-graphql_cardano-graphql_1 keeps restarting due to this error related with 1589369664961_init/up.sql.
DOCKER_BUILDKIT=1 \
COMPOSE_DOCKER_CLI_BUILD=1 \
RESTORE_SNAPSHOT=https://update-cardano-mainnet.iohk.io/cardano-db-sync/13/db-sync-snapshot-schema-13-block-7560650-x86_64.tgz \
docker-compose up -d --build &&\
docker-compose logs -f

docker ps result:
CONTAINER ID   IMAGE                                                 COMMAND                  CREATED        STATUS          PORTS                                                                       NAMES
550b5a0b3d00   inputoutput/cardano-db-sync:12.0.0                    "/nix/store/5ghw8rqx…"   18 hours ago   Up 18 hours                                                                                cardano-graphql_cardano-db-sync-extended_1
0556554a09e6   inputoutput/cardano-graphql-hasura:6.2.0              "docker-entrypoint.s…"   18 hours ago   Up 18 hours     0.0.0.0:8090->8080/tcp, :::8090->8080/tcp                                   cardano-graphql_hasura_1
7dc02c06cf4e   inputoutput/cardano-graphql:6.2.0-mainnet             "node index.js"          18 hours ago   Up 56 seconds   0.0.0.0:3100->3100/tcp, :::3100->3100/tcp                                   cardano-graphql_cardano-graphql_1
6b1e7a19e0d6   postgres:11.5-alpine                                  "docker-entrypoint.s…"   18 hours ago   Up 18 hours     0.0.0.0:5432->5432/tcp, :::5432->5432/tcp                                   cardano-graphql_postgres_1
6c35c01400ee   cardanosolutions/cardano-node-ogmios:v5.1.0-mainnet   "bash cardano-node-o…"   18 hours ago   Up 18 hours     3000/tcp, 12788/tcp, 0.0.0.0:1337->1337/tcp, :::1337->1337/tcp, 12798/tcp   cardano-graphql_cardano-node-ogmios_1

Logs of cardano-graphql_cardano-graphql_1:
{"name":"cardano-graphql","hostname":"7dc02c06cf4e","pid":1,"level":30,"module":"Server","msg":"Initializing","time":"2022-08-03T06:59:29.716Z","v":0}
{"name":"cardano-graphql","hostname":"7dc02c06cf4e","pid":1,"level":30,"module":"HasuraClient","msg":"Initializing","time":"2022-08-03T06:59:30.152Z","v":0}
{"name":"cardano-graphql","hostname":"7dc02c06cf4e","pid":1,"level":50,"msg":"Command failed: /usr/local/bin/hasura --skip-update-check --project /app/packages/api-cardano-db-hasura/hasura/project --endpoint http://hasura:8080 migrate apply --up all\ntime=\"2022-08-03T07:02:58Z\" level=fatal msg=\"apply failed: [postgres-error] query execution failed ($.args[0].args)\\r\\nFile: '1589369664961_init/up.sql'\\r\\n{\\n    \\\"check_metadata_consistency\\\": false,\\n    \\\"sql\\\": \\\"\\\\nCREATE VIEW \\\\\\\"AdaPots\\\\\\\" AS\\\\n  SELECT\\\\n    epoch_no AS \\\\\\\"epochNo\\\\\\\",\\\\n    deposits,\\\\n    fees,\\\\n    reserves,\\\\n    rewards,\\\\n    slot_no AS \\\\\\\"slotNo\\\\\\\",\\\\n    treasury,\\\\n    utxo\\\\nFROM ada_pots;\\\\n\\\\nCREATE TABLE IF NOT EXISTS \\\\\\\"Asset\\\\\\\" (\\\\n    \\\\\\\"assetId\\\\\\\" BYTEA PRIMARY KEY,\\\\n    \\\\\\\"assetName\\\\\\\" BYTEA,\\\\n    \\\\\\\"decimals\\\\\\\" INT,\\\\n    \\\\\\\"description\\\\\\\" VARCHAR(500),\\\\n    \\\\\\\"fingerprint\\\\\\\" CHAR(44),\\\\n    \\\\\\\"firstAppearedInSlot\\\\\\\" INT,\\\\n    \\\\\\\"logo\\\\\\\" VARCHAR(65536),\\\\n    \\\\\\\"metadataHash\\\\\\\" CHAR(40),\\\\n    \\\\\\\"name\\\\\\\" VARCHAR(50),\\\\n    \\\\\\\"policyId\\\\\\\" BYTEA,\\\\n    \\\\\\\"ticker\\\\\\\" VARCHAR(9),\\\\n    \\\\\\\"url\\\\\\\" VARCHAR(250)\\\\n);\\\\n\\\\nCREATE VIEW \\\\\\\"Block\\\\\\\" AS\\\\n SELECT (COALESCE(( SELECT sum((tx.fee)::bigint) AS sum\\\\n           FROM tx\\\\n          WHERE (tx.block_id = block.id)), (0)::NUMERIC))::bigint AS fees,\\\\n    block.hash,\\\\n    block.block_no AS \\\\\\\"number\\\\\\\",\\\\n    block.op_cert AS \\\\\\\"opCert\\\\\\\",\\\\n    previous_block.hash AS \\\\\\\"previousBlockHash\\\\\\\",\\\\n    next_block.hash AS \\\\\\\"nextBlockHash\\\\\\\",\\\\n    jsonb_build_object('major', block.proto_major, 'minor', block.proto_minor) AS \\\\\\\"protocolVersion\\\\\\\",\\\\n    block.size,\\\\n    block.tx_count AS \\\\\\\"transactionsCount\\\\\\\",\\\\n    block.epoch_no AS \\\\\\\"epochNo\\\\\\\",\\\\n    block.\\\\\\\"time\\\\\\\" AS \\\\\\\"forgedAt\\\\\\\",\\\\n    block.epoch_slot_no AS \\\\\\\"slotInEpoch\\\\\\\",\\\\n    block.slot_no AS \\\\\\\"slotNo\\\\\\\",\\\\n    slot_leader.id AS \\\\\\\"slot_leader_id\\\\\\\",\\\\n    slot_leader.pool_hash_id AS \\\\\\\"pool_hash_id\\\\\\\",\\\\n    block.vrf_key As \\\\\\\"vrfKey\\\\\\\"\\\\n   FROM (((block\\\\n     LEFT JOIN block previous_block ON ((block.previous_id = previous_block.id)))\\\\n     LEFT JOIN block next_block ON ((next_block.previous_id = block.id)))\\\\n     LEFT JOIN slot_leader ON ((block.slot_leader_id = slot_leader.id)));\\\\n\\\\nCREATE OR REPLACE VIEW \\\\\\\"Cardano\\\\\\\" AS\\\\n SELECT block.block_no AS \\\\\\\"tipBlockNo\\\\\\\",\\\\n    block.epoch_no AS \\\\\\\"currentEpochNo\\\\\\\"\\\\n   FROM block\\\\n  WHERE (block.block_no IS NOT NULL)\\\\n  ORDER BY block.block_no DESC\\\\n LIMIT 1;\\\\n \\\\nCREATE VIEW \\\\\\\"Collateral\\\\\\\" AS\\\\nSELECT\\\\n  source_tx_out.address,\\\\n  source_tx_out.value,\\\\n  tx.hash AS \\\\\\\"txHash\\\\\\\",\\\\n  source_tx.hash AS \\\\\\\"sourceTxHash\\\\\\\",\\\\n  collateral_tx_in.tx_out_index AS \\\\\\\"sourceTxIndex\\\\\\\",\\\\n  source_tx_out.id AS source_tx_out_id\\\\nFROM\\\\n  tx\\\\nJOIN collateral_tx_in\\\\n  ON collateral_tx_in.tx_in_id = tx.id\\\\nJOIN tx_out AS source_tx_out\\\\n  ON collateral_tx_in.tx_out_id = source_tx_out.tx_id\\\\n  AND collateral_tx_in.tx_out_index = source_tx_out.index\\\\nJOIN tx AS source_tx\\\\n  ON source_tx_out.tx_id = source_tx.id;\\\\n\\\\nCREATE VIEW \\\\\\\"Delegation\\\\\\\" AS\\\\nSELECT\\\\n  delegation.id AS \\\\\\\"id\\\\\\\",\\\\n  stake_address.view AS \\\\\\\"address\\\\\\\",\\\\n  delegation.redeemer_id AS \\\\\\\"redeemerId\\\\\\\",\\\\n  delegation.tx_id AS \\\\\\\"tx_id\\\\\\\",\\\\n  pool_hash_id AS \\\\\\\"pool_hash_id\\\\\\\"\\\\nFROM delegation\\\\nJOIN stake_address on delegation.addr_id = stake_address.id;\\\\n\\\\nCREATE VIEW \\\\\\\"Epoch\\\\\\\" AS\\\\nSELECT\\\\n  epoch.fees AS \\\\\\\"fees\\\\\\\",\\\\n  epoch.out_sum AS \\\\\\\"output\\\\\\\",\\\\n  epoch.no AS \\\\\\\"number\\\\\\\",\\\\n  epoch_param.nonce AS \\\\\\\"nonce\\\\\\\",\\\\n  epoch.tx_count AS \\\\\\\"transactionsCount\\\\\\\",\\\\n  epoch.start_time AS \\\\\\\"startedAt\\\\\\\",\\\\n  epoch.end_time AS \\\\\\\"lastBlockTime\\\\\\\",\\\\n  epoch.blk_count AS \\\\\\\"blocksCount\\\\\\\"\\\\nFROM epoch\\\\n  LEFT JOIN epoch_param on epoch.no = epoch_param.epoch_no;\\\\n\\\\nCREATE VIEW \\\\\\\"ShelleyEpochProtocolParams\\\\\\\" AS\\\\nSELECT\\\\n  epoch_param.influence AS \\\\\\\"a0\\\\\\\",\\\\n  epoch_param.coins_per_utxo_word AS \\\\\\\"coinsPerUtxoWord\\\\\\\",\\\\n  epoch_param.collateral_percent AS \\\\\\\"collateralPercent\\\\\\\",\\\\n  cost_model.costs AS \\\\\\\"costModels\\\\\\\",\\\\n  epoch_param.decentralisation AS \\\\\\\"decentralisationParam\\\\\\\",\\\\n  epoch_param.max_collateral_inputs AS \\\\\\\"maxCollateralInputs\\\\\\\",\\\\n  epoch_param.max_epoch AS \\\\\\\"eMax\\\\\\\",\\\\n  epoch_param.epoch_no AS \\\\\\\"epoch_no\\\\\\\",\\\\n  epoch_param.entropy AS \\\\\\\"extraEntropy\\\\\\\",\\\\n  epoch_param.key_deposit AS \\\\\\\"keyDeposit\\\\\\\",\\\\n  epoch_param.max_block_size AS \\\\\\\"maxBlockBodySize\\\\\\\",\\\\n  epoch_param.max_block_ex_mem AS \\\\\\\"maxBlockExMem\\\\\\\",\\\\n  epoch_param.max_block_ex_steps AS \\\\\\\"maxBlockExSteps\\\\\\\",\\\\n  epoch_param.max_bh_size AS \\\\\\\"maxBlockHeaderSize\\\\\\\",\\\\n  epoch_param.max_tx_ex_mem AS \\\\\\\"maxTxExMem\\\\\\\",\\\\n  epoch_param.max_tx_ex_steps AS \\\\\\\"maxTxExSteps\\\\\\\",\\\\n  epoch_param.max_tx_size AS \\\\\\\"maxTxSize\\\\\\\",\\\\n  epoch_param.max_val_size AS \\\\\\\"maxValSize\\\\\\\",\\\\n  epoch_param.min_fee_a AS \\\\\\\"minFeeA\\\\\\\",\\\\n  epoch_param.min_fee_b AS \\\\\\\"minFeeB\\\\\\\",\\\\n  epoch_param.min_pool_cost AS \\\\\\\"minPoolCost\\\\\\\",\\\\n  epoch_param.min_utxo_value AS \\\\\\\"minUTxOValue\\\\\\\",\\\\n  epoch_param.optimal_pool_count AS \\\\\\\"nOpt\\\\\\\",\\\\n  epoch_param.pool_deposit AS \\\\\\\"poolDeposit\\\\\\\",\\\\n  epoch_param.price_mem AS \\\\\\\"priceMem\\\\\\\",\\\\n  epoch_param.price_step AS \\\\\\\"priceStep\\\\\\\",\\\\n  jsonb_build_object('major', epoch_param.protocol_major, 'minor', epoch_param.protocol_major) AS \\\\\\\"protocolVersion\\\\\\\",\\\\n  epoch_param.monetary_expand_rate AS \\\\\\\"rho\\\\\\\",\\\\n  epoch_param.treasury_growth_rate AS \\\\\\\"tau\\\\\\\"\\\\nFROM epoch_param\\\\nJOIN cost_model\\\\n  ON epoch_param.cost_model_id = cost_model.id;\\\\n\\\\nCREATE VIEW \\\\\\\"Redeemer\\\\\\\" AS\\\\nSELECT\\\\n  redeemer.fee AS \\\\\\\"fee\\\\\\\",\\\\n  redeemer.id AS \\\\\\\"id\\\\\\\",\\\\n  redeemer.index AS \\\\\\\"index\\\\\\\",\\\\n  redeemer.purpose AS \\\\\\\"purpose\\\\\\\",\\\\n  redeemer.script_hash AS \\\\\\\"scriptHash\\\\\\\",\\\\n  redeemer.tx_id AS \\\\\\\"txId\\\\\\\",\\\\n  redeemer.unit_mem AS \\\\\\\"unitMem\\\\\\\",\\\\n  redeemer.unit_steps AS \\\\\\\"unitSteps\\\\\\\"\\\\nFROM redeemer;\\\\n\\\\nCREATE VIEW \\\\\\\"Reward\\\\\\\" AS\\\\nSELECT\\\\n  reward.amount,\\\\n  stake_address.view AS \\\\\\\"address\\\\\\\",\\\\n  reward.earned_epoch AS \\\\\\\"earnedInEpochNo\\\\\\\",\\\\n  reward.pool_id AS pool_hash_id,\\\\n  reward.spendable_epoch AS \\\\\\\"receivedInEpochNo\\\\\\\",\\\\n  reward.type AS \\\\\\\"type\\\\\\\"\\\\nFROM reward\\\\nJOIN stake_address on reward.addr_id = stake_address.id;\\\\n\\\\nCREATE VIEW \\\\\\\"Script\\\\\\\" AS\\\\nSELECT\\\\n  script.hash AS \\\\\\\"hash\\\\\\\",\\\\n  script.serialised_size AS \\\\\\\"serialisedSize\\\\\\\",\\\\n  script.type AS \\\\\\\"type\\\\\\\",\\\\n  script.tx_id AS \\\\\\\"txId\\\\\\\"\\\\nFROM script;\\\\n\\\\nCREATE VIEW \\\\\\\"SlotLeader\\\\\\\" AS\\\\nSELECT\\\\n  slot_leader.hash AS \\\\\\\"hash\\\\\\\",\\\\n  slot_leader.id AS \\\\\\\"id\\\\\\\",\\\\n  slot_leader.description AS \\\\\\\"description\\\\\\\",\\\\n  slot_leader.pool_hash_id AS \\\\\\\"pool_hash_id\\\\\\\"\\\\nFROM slot_leader;\\\\n\\\\nCREATE VIEW \\\\\\\"StakeDeregistration\\\\\\\" AS\\\\nSELECT\\\\n  stake_deregistration.id AS \\\\\\\"id\\\\\\\",\\\\n  stake_address.view AS \\\\\\\"address\\\\\\\",\\\\n  stake_deregistration.redeemer_id AS \\\\\\\"redeemerId\\\\\\\",\\\\n  stake_deregistration.tx_id AS \\\\\\\"tx_id\\\\\\\"\\\\nFROM stake_deregistration\\\\nJOIN stake_address on stake_deregistration.addr_id = stake_address.id;\\\\n\\\\nCREATE VIEW \\\\\\\"StakePool\\\\\\\" AS\\\\nWITH\\\\n  latest_block_times AS (\\\\n    SELECT pool.hash_id, max(block.time) AS blockTime\\\\n    FROM pool_update AS pool\\\\n    JOIN tx ON pool.registered_tx_id = tx.id\\\\n    JOIN block ON tx.block_id = block.id\\\\n    group by pool.hash_id\\\\n)\\\\nSELECT\\\\n  pool.fixed_cost AS \\\\\\\"fixedCost\\\\\\\",\\\\n  pool_hash.hash_raw AS \\\\\\\"hash\\\\\\\",\\\\n  pool_hash.view AS \\\\\\\"id\\\\\\\",\\\\n  pool.hash_id AS \\\\\\\"hash_id\\\\\\\",\\\\n  pool.id AS \\\\\\\"update_id\\\\\\\",\\\\n  pool.margin AS \\\\\\\"margin\\\\\\\",\\\\n  pool_metadata_ref.hash AS \\\\\\\"metadataHash\\\\\\\",\\\\n  block.block_no AS \\\\\\\"blockNo\\\\\\\",\\\\n  pool.registered_tx_id AS \\\\\\\"updated_in_tx_id\\\\\\\",\\\\n  pool.pledge AS \\\\\\\"pledge\\\\\\\",\\\\n  stake_address.view AS \\\\\\\"rewardAddress\\\\\\\",\\\\n  pool_metadata_ref.url AS \\\\\\\"url\\\\\\\"\\\\nFROM pool_update AS pool\\\\n  LEFT JOIN pool_metadata_ref ON pool.meta_id = pool_metadata_ref.id\\\\n  INNER JOIN tx ON pool.registered_tx_id = tx.id\\\\n  INNER JOIN latest_block_times ON latest_block_times.hash_id = pool.hash_id\\\\n  INNER JOIN block ON tx.block_id = block.id AND latest_block_times.blockTime = block.time\\\\n  JOIN stake_address on pool.reward_addr = stake_address.hash_raw\\\\n  JOIN pool_hash on pool_hash.id = pool.hash_id;\\\\n\\\\nCREATE VIEW \\\\\\\"StakePoolOwner\\\\\\\" AS\\\\nSELECT\\\\n  stake_address.hash_raw as \\\\\\\"hash\\\\\\\",\\\\n  pool_owner.pool_hash_id as \\\\\\\"pool_hash_id\\\\\\\"\\\\nFROM pool_owner\\\\n  LEFT JOIN stake_address ON pool_owner.addr_id = stake_address.id;\\\\n\\\\nCREATE VIEW \\\\\\\"StakePoolRetirement\\\\\\\" AS\\\\nSELECT\\\\n  retiring_epoch as \\\\\\\"inEffectFrom\\\\\\\",\\\\n  announced_tx_id as \\\\\\\"tx_id\\\\\\\",\\\\n  hash_id AS \\\\\\\"pool_hash_id\\\\\\\"\\\\nFROM pool_retire;\\\\n\\\\nCREATE VIEW \\\\\\\"StakeRegistration\\\\\\\" AS\\\\nSELECT\\\\n  stake_registration.id AS \\\\\\\"id\\\\\\\",\\\\n  stake_address.view AS \\\\\\\"address\\\\\\\",\\\\n  stake_registration.tx_id AS \\\\\\\"tx_id\\\\\\\"\\\\nFROM stake_registration\\\\nJOIN stake_address on stake_registration.addr_id = stake_address.id;\\\\n\\\\nCREATE VIEW \\\\\\\"ActiveStake\\\\\\\" AS\\\\nSELECT\\\\n  stake_address.view AS \\\\\\\"address\\\\\\\",\\\\n  amount AS \\\\\\\"amount\\\\\\\",\\\\n  epoch_no as \\\\\\\"epochNo\\\\\\\",\\\\n  epoch_stake.id AS \\\\\\\"id\\\\\\\",\\\\n  pool_hash.hash_raw AS \\\\\\\"stakePoolHash\\\\\\\",\\\\n  pool_hash.view AS \\\\\\\"stakePoolId\\\\\\\"\\\\nFROM epoch_stake\\\\nJOIN pool_hash\\\\n  ON pool_hash.id = epoch_stake.pool_id\\\\nJOIN stake_address on epoch_stake.addr_id = stake_address.id;\\\\n\\\\nCREATE VIEW \\\\\\\"TokenMint\\\\\\\" AS\\\\nSELECT\\\\n  CAST(CONCAT(multi_asset.policy, RIGHT(CONCAT(E'\\\\\\\\\\\\\\\\', multi_asset.name), -3)) as BYTEA) as \\\\\\\"assetId\\\\\\\",\\\\n  multi_asset.name AS \\\\\\\"assetName\\\\\\\",\\\\n  multi_asset.policy AS \\\\\\\"policyId\\\\\\\",\\\\n  quantity,\\\\n  tx_id\\\\nFROM ma_tx_mint\\\\nJOIN multi_asset\\\\n  ON ma_tx_mint.ident = multi_asset.id;\\\\n\\\\nCREATE VIEW \\\\\\\"TokenInOutput\\\\\\\" AS\\\\nSELECT\\\\n  CAST(CONCAT(policy, RIGHT(CONCAT(E'\\\\\\\\\\\\\\\\', name), -3)) as BYTEA) as \\\\\\\"assetId\\\\\\\",\\\\n  name as \\\\\\\"assetName\\\\\\\",\\\\n  policy AS \\\\\\\"policyId\\\\\\\",\\\\n  quantity,\\\\n  tx_out_id\\\\nFROM ma_tx_out\\\\nJOIN multi_asset\\\\n  ON ma_tx_out.ident = multi_asset.id;\\\\n\\\\nCREATE VIEW \\\\\\\"Transaction\\\\\\\" AS\\\\nSELECT\\\\n  block.hash AS \\\\\\\"blockHash\\\\\\\",\\\\n  tx.block_index AS \\\\\\\"blockIndex\\\\\\\",\\\\n  tx.deposit AS \\\\\\\"deposit\\\\\\\",\\\\n  COALESCE(tx.fee, 0) AS fee,\\\\n  tx.hash,\\\\n  tx.id,\\\\n  block.time AS \\\\\\\"includedAt\\\\\\\",\\\\n  tx.invalid_before AS \\\\\\\"invalidBefore\\\\\\\",\\\\n  tx.invalid_hereafter AS \\\\\\\"invalidHereafter\\\\\\\",\\\\n  tx.script_size AS \\\\\\\"scriptSize\\\\\\\",\\\\n  tx.size,\\\\n  CAST(COALESCE((SELECT SUM(\\\\\\\"value\\\\\\\") FROM tx_out WHERE tx_id = tx.id), 0) AS bigint) AS \\\\\\\"totalOutput\\\\\\\",\\\\n  tx.valid_contract AS \\\\\\\"validContract\\\\\\\"\\\\nFROM\\\\n  tx\\\\nINNER JOIN block\\\\n  ON block.id = tx.block_id;\\\\n\\\\nCREATE VIEW \\\\\\\"TransactionInput\\\\\\\" AS\\\\nSELECT\\\\n  source_tx_out.address,\\\\n  tx_in.redeemer_id AS \\\\\\\"redeemerId\\\\\\\",\\\\n  source_tx_out.value,\\\\n  tx.hash AS \\\\\\\"txHash\\\\\\\",\\\\n  source_tx.hash AS \\\\\\\"sourceTxHash\\\\\\\",\\\\n  tx_in.tx_out_index AS \\\\\\\"sourceTxIndex\\\\\\\",\\\\n  source_tx_out.id AS source_tx_out_id\\\\nFROM\\\\n  tx\\\\nJOIN tx_in\\\\n  ON tx_in.tx_in_id = tx.id\\\\nJOIN tx_out AS source_tx_out\\\\n  ON tx_in.tx_out_id = source_tx_out.tx_id\\\\n  AND tx_in.tx_out_index = source_tx_out.index\\\\nJOIN tx AS source_tx\\\\n  ON source_tx_out.tx_id = source_tx.id;\\\\n\\\\nCREATE VIEW \\\\\\\"TransactionOutput\\\\\\\" AS\\\\nSELECT\\\\n  address,\\\\n  tx_out.address_has_script AS \\\\\\\"addressHasScript\\\\\\\",\\\\n  value,\\\\n  tx.hash AS \\\\\\\"txHash\\\\\\\",\\\\n  tx_out.id,\\\\n  index\\\\nFROM tx\\\\nJOIN tx_out\\\\n  ON tx.id = tx_out.tx_id;\\\\n\\\\nCREATE VIEW \\\\\\\"Utxo\\\\\\\" AS SELECT\\\\n  address,\\\\n  tx_out.address_has_script AS \\\\\\\"addressHasScript\\\\\\\",\\\\n  value,\\\\n  tx.hash AS \\\\\\\"txHash\\\\\\\",\\\\n  tx_out.id,\\\\n  index\\\\nFROM tx\\\\nJOIN tx_out\\\\n  ON tx.id = tx_out.tx_id\\\\nLEFT OUTER JOIN tx_in\\\\n  ON tx_out.tx_id = tx_in.tx_out_id\\\\n  AND tx_out.index = tx_in.tx_out_index\\\\nWHERE tx_in.tx_in_id IS NULL;\\\\n\\\\nCREATE VIEW \\\\\\\"Withdrawal\\\\\\\" AS\\\\nSELECT\\\\n  withdrawal.amount AS \\\\\\\"amount\\\\\\\",\\\\n  withdrawal.id AS \\\\\\\"id\\\\\\\",\\\\n  stake_address.view \\\\\\\"address\\\\\\\",\\\\n  withdrawal.redeemer_id AS \\\\\\\"redeemerId\\\\\\\",\\\\n  withdrawal.tx_id AS \\\\\\\"tx_id\\\\\\\"\\\\nFROM withdrawal\\\\nJOIN stake_address on withdrawal.addr_id = stake_address.id;\\\\n\\\\nCREATE INDEX idx_block_hash\\\\n    ON block(hash);\\\\n\\\\nCREATE INDEX idx_multi_asset_name\\\\n    ON multi_asset(name);\\\\n\\\\nCREATE INDEX idx_multi_asset_policy\\\\n    ON multi_asset(policy);\\\\n\\\\nCREATE INDEX idx_reward_type\\\\n    ON reward(type);\\\\n\\\\nCREATE INDEX idx_tx_hash\\\\n    ON tx(hash);\\\\n\\\\nCREATE INDEX idx_tx_in_consuming_tx\\\\n   ON tx_in(tx_out_id);\\\\n\\\\nCREATE INDEX idx_tx_out_tx\\\\n    ON tx_out(tx_id);\\\\n\\\\nCREATE function utxo_set_at_block(\\\\\\\"hash\\\\\\\" hash32type)\\\\nRETURNS SETOF \\\\\\\"TransactionOutput\\\\\\\" AS $$\\\\n  SELECT\\\\n    \\\\\\\"TransactionOutput\\\\\\\".address,\\\\n    \\\\\\\"TransactionOutput\\\\\\\".\\\\\\\"addressHasScript\\\\\\\",\\\\n    \\\\\\\"TransactionOutput\\\\\\\".value,\\\\n    \\\\\\\"TransactionOutput\\\\\\\".\\\\\\\"txHash\\\\\\\",\\\\n    \\\\\\\"TransactionOutput\\\\\\\".\\\\\\\"id\\\\\\\",\\\\n    \\\\\\\"TransactionOutput\\\\\\\".index\\\\n  FROM tx\\\\n  JOIN tx_out\\\\n    ON tx.id = tx_out.tx_id\\\\n  JOIN \\\\\\\"TransactionOutput\\\\\\\"\\\\n    ON tx.hash = \\\\\\\"TransactionOutput\\\\\\\".\\\\\\\"txHash\\\\\\\"\\\\n  LEFT OUTER JOIN tx_in\\\\n    ON tx_out.tx_id = tx_in.tx_out_id\\\\n    AND tx_out.index = tx_in.tx_out_index\\\\n  WHERE tx_in.tx_in_id IS NULL\\\\n  AND tx.block_id \\\\u003c= (SELECT id FROM block WHERE hash = \\\\\\\"hash\\\\\\\")\\\\n$$ LANGUAGE SQL stable;\\\\n\\\\n\\\"\\n}\\r\\n[42703] FatalError: column epoch_param.coins_per_utxo_word does not exist\"\n","time":"2022-08-03T07:02:58.766Z","v":0}

It looks like you are restoring a db-sync 13 snapshot while your db-sync version is 12.
For the moment there don't seem to be anymore snapshots for db-sync 12.
My guess is that if you remove the snapshot option and have it sync from scratch it will just work - but this will probably take a few days.
I wouldn't suggest using version 13 just yet since there are no compatible downstream components for this just yet. Maybe if you wait a few days for the official releases that would become an option.

That makes sense but when I let db-sync get sync via genesis it takes too much time. Byron era goes smooth but when it reaches to Shelly era it takes 1 day to move from epoch 287 to 288.

How much IOPS does your machine have? This slow syncing sounds like you need higher performing storage. For db-sync the requirement is at least 60.000 IOPS, but higher is better of course.
If you have lower IOPS you'll see:

syncing be slow
falling behind the tip (even if you ever catch up)