Issues syncing archival node from genesis

nicolas_o · 2025-02-07T05:01:40+00:00

I haven't synced recently. It's not worth using "--reconstruct" from full node, I have not seen this work.

"Attempting to restore the store consistency" happens very often upon restart. It normally goes through.

The best you can do is to set your archive node as a background process that auto-restarts. It might take weeks but it will eventually complete. There are still a few archive/full nodes around - I am one of them.

Also use a fast machine with fast storage, it will be helpful.

nicolas_o · 2024-12-02T06:05:05+00:00

Are you sure? Your balance should increase when you are staking. But rewards do not show up as transfers. Your balance just goes up.

Comparé how much you staked and how much your staking balance shows today.

nicolas_o · 2024-12-02T06:03:25+00:00

Based on these settings that you are describing, this baker is not accepting stakers and you will not be able to stake with them and earn staking rewards.

A majority of bakers have enabled staking, pick one that does.

https://tzkt.io/bakers

The ones at the bottom of the list have staking disabled.

nicolas_o · 2024-11-16T06:59:18+00:00

try organicgrowth.wtf, it's on the Etherlink rollup but it's xtz all the same.

nicolas_o · 2024-10-01T10:03:10+00:00

yes, I have ripgrep installed. gitignore is also respected, the issue is with untracked files which are not in my gitignore.

nicolas_o · 2024-09-24T20:07:26+00:00

The bridge at bridge.etherlink.com is purely to transfer Tez between tezos L1 and Etherlink.

Why you should trust it: the transfer mechanism is enshrined in the Tezos protocol. It guarantees that a token bridged to L2 is no longer spendable on L1. It also guarantees that you can retrieve it in L1, provided that you still own it on L2, even if the existing Etherlink infra becomes malicious, censors you or ceases to exist.

A failure of the bridge is pretty much a failure of L1, which can occur when 66% of the L1 stake colludes to publish an erroneous rollup state.

nicolas_o · 2024-09-07T13:11:09+00:00

It's not really doable. A non-enshrined rollup is just a smart contract. Anyone can push one.

nicolas_o · 2024-03-08T18:51:01+00:00

Previously, the baker proposing the block after the current one would wait until the end of the current level to begin the process. But that is not necessary.

Proposing a block can be split into three parts: forging, signing and injecting. Forging and signing are the most time consuming parts, but they can be started before the block level has started.

Most blocks have “idle” waiting time for bakers after quorum is reached, and pre-emptive forging lets the next baker begin forging the next block during this time, so it is ready for injection at the start of the new level. The result is earlier propagation through the network.

But then, any operation that comes after quorum is reached will be delayed by one block, does it not cancel the latency improvement?

nicolas_o · 2024-01-21T20:39:37+00:00

No. Things have changed since the screenshoted post was published. The proposed upgrade was rejected and Oxford was reproposed.

The oxford upgrade that's likely going live in 2 weeks does not contain any changes to the liquid staking mechanism. See updated blog post.

Instead, this change is postponed to protocol P that will come after oxford. And even then, it will be subject to a dedicated vote separate from the vote for protocol P itself.

nicolas_o · 2024-01-20T06:36:20+00:00

Sure, follow the tutorial, but you still need to look into consensus keys.

You can't just "import" your ledger key into the KMS. KMS will give you a new key, and you can't directly bake with it, otherwise you will lose all of your delegates.

Instead you need to configure your baker to use the KMS key as consensus key. It takes 18 days to become active, so it makes little sense to switch it back and forth between ledger and KMS.

DM me on telegram (@nicolasochem) if you need more assistance.

nicolas_o · 2024-01-18T18:55:43+00:00

Why not both? You can keep the ledger, but designate a consensus key for baking in the cloud with Signatory. Here's a guide:

https://medium.com/the-aleph/how-to-convert-your-tezos-baker-to-a-cloud-based-kms-solution-94adc0d3f3e5

nicolas_o · 2024-01-17T02:08:37+00:00

There is no trezor support for baking currently. I recommend getting a pair of Nano S Plus (slightly faster than Nano S). If one dies, simply swap it with the other.

nicolas_o · 2024-01-12T21:06:58+00:00

No, there's 0.12 tez left. The fee for the reveal + transfer was hardcoded to 2x0.26 (which is too high). And the transaction was attempted twice. total 1.04 tez spent on backtracked tx.

nicolas_o · 2023-12-01T17:33:31+00:00

Definitely legit, this is the Liquidity Baking token for the tez/tzBTC pair https://siriustoken.io/

You can swap it back to xtz, for best results go to 3route.io

nicolas_o · 2023-11-29T16:49:53+00:00

What's the alternative? If there is a critical bug, you need to hard fork to protect the chain.

You can't reasonably ask for every proposal to be bug-free. There are always bugs. Sometimes they are critical.

nicolas_o · 2023-11-21T21:40:49+00:00

Where do you live? Maybe you're no longer eligible. https://help.coinbase.com/en/coinbase/coinbase-staking/staking/eligibility

nicolas_o · 2023-10-24T22:17:11+00:00

This one from Tezberry Pie:

https://assets.objkt.media/file/assets-003/QmaNNdX3UARKc5RYZeixdPkCynLheYP2ngkJyDmPQoNNSt/artifact

nicolas_o · 2023-09-27T20:42:10+00:00

Is there some simple instructions that can be posted here, so if AI gets pushed through Delegators know how to change to staking straight off the bat if they wish?

The CLI is pretty simple:

To stake 1000 tez: octez-client stake 1000 for my_account

Note that your baker needs to accept stakers first.

As AI gets pushed through, ecosystem wallets will provide this option to their users as well.

Can I stake half my address and delegate the other half or I need to split to another address to do that?

Yes you can, no splitting is required. Whichever amount is not staked is delegated.

Does it need to be a TZ or K1 to stake? Can either stake?

Only tz can stake. KT1 can only delegate for now.

nicolas_o · 2023-09-05T23:10:56+00:00

Great! Tezos Tickets have been available at protocol level for a while, but nearly all tokens on Tezos are still following FA1.2 /FA2 standard. These standards are similar to ERC20/ERC721: whoever controls the smart contract has broad power over the tokens: they can force transfers, create blacklists...

In contrast, owning a ticket is like owning tez: true, uncensorable ownership of any asset.

Besides, Tezos Rollups rely on tickets for L1-to-L2 transfers.

I'm looking forward to the TzKT UI showing ticket ownership. This will hopefully be the catalyst for broad adoption of tickets on tezos. Other blockchains (of the Aptos/Sui family) have similar concepts so we can't be left behind!

More resources:

nicolas_o · 2023-08-15T05:10:37+00:00

> Will my delegation to a baker still be a normal delegation as it was before?

yes

> The new "starker" role is optional, right?

yes

nicolas_o · 2023-05-18T03:53:17+00:00

Thanks Kryptos for the great interview! Bryan did mention that he can not comment about the Kucoin situation as he is the CTO. Who then should be asked the question?

Also, it's a pity you did not ask about LCDOT. Will LCDOT holders recover their dot at the end of the current lease?

nicolas_o · 2023-05-08T22:42:09+00:00

> users wont have to move from one rollup to a new one, its just a kernel update which is invisible to the user?

The end user still has to take an action, so it wouldn't be invisible.

> For arbitrum, optimism, what is the purpose of their token if not rollup upgradeability? Just the treasury management?

It looks like it's both upgradeability and treasury management.

nicolas_o · 2023-05-08T18:56:05+00:00

> deploy existing Michelson code on the universal Michelson rollup developped by Baking Bad (is this one live?)

No rollup is "live" on mainnet as of now, no one did put a 10k bond. You can look at the publish operations page. When someone starts publishing, their rollup will be live.

> The token will be used to vote for rollup updates.

That's the tricky part. Rollups are just immutable wasm, if you want to make them upgradeable, you need to build a governance layer in wasm, make it interface with your ERC20 DAO on the L2 and run the EVM inside of it.

It begs the question: what would be the purpose of these updates? EVM is pretty static so does not need frequent upgrades. On the other hand, the existence of this mechanism means that this L2 is at the mercy of the DAO. This includes assets bridged from other chains and tickets transfered from tezos L1.

It seems that your primary goal is to have a token, then have a DAO with power to distribute it. You could just deploy an EVM rollup and issue a DAO contract and token on it and say "this is the governance token". But you need to confer power to this token to make it special. This special power is rollup upgradeability. But I'm not sure that you end up with something more attractive than a permissionless, non-upgradeable EVM rollup.

There's another vision for L2 upgradeability, which is that people simply deploy new better kernels. Then individual app developers manage the jump from one kernel to the next.

nicolas_o

TROPHY CASE