[Sozo] Output block # after successful migration

[broody]

When migrating world, it would be useful to show the block number the world contract was deployed on. Useful to have when starting torii with --start-block. Currently using another cli to get this value prior to migration.

Perhaps something like this?
🎉 Successfully migrated World on block #1337 at address 0x788f5fd335d29ed5f8686982079cc3aa9c82aa41968f759b2c3d0be8d5fa0c4

[ponderingdemocritus]

Great idea! @aymericdelab and I had the exact same thought yesterday

[broody]

Ugh commented on the wrong issue. Meant to say it here -

Ah just occurred to me, perhaps an enhancement to sozo migrate is updating the manifest to include block_height and rpc_url after migration, this way torii just needs the manifest param to start indexing.

manifest.json

"rpc_url" : "https://rinnegan.madara.zone",
"world": {
"name": "world",
"address": "0x123",
"block_height": "1337"
"class_hash": "0x7f07c1861ee2df73f81685cdda7e51978ef0f50154a6a8c11e4af6b55d08ebf"
},

[lambda-0x]

i can give this a try

[lambda-0x]

@broody do you mean manifest.json generated by sozo inside ./target/dev folder? I can see world object in that file but not rpc_url.

Also is the block_height only needed for world contract or all contracts present in that file?

[broody]

Thanks! I believe @tarrencev had some thoughts about manifest.json, could possibly address in another issue. Being able to output block height on just sozo migrate would be great for now.

@broody do you mean manifest.json generated by sozo inside ./target/dev folder? I can see world object in that file but not rpc_url.

Right, I had added that as an example to illustrate.

Also is the block_height only needed for world contract or all contracts present in that file?

From torii perspective, we just need it for world contract, but perhaps good idea to include for all.

[lambda-0x]

Thanks! I believe @tarrencev had some thoughts about manifest.json, could possibly address in another issue. Being able to output block height on just sozo migrate would be great for now.

Okay then i will clean up the linked PR and change from draft to ready for review tonight

[tarrencev]

@lambda-0x thanks for your contribution here! I think adding chain specific deployment information to the manifest is a great idea too. Would you like to make a proposal on the schema?

[lambda-0x]

@tarrencev i am not really sure what kind of information would be useful, i can think of block_number (as requested by @broody which already has a usecase), block_hash, transaction_hash (in which particular contract was deployed), but not sure what other two would be used for.

Is there anything else that might be helpful?

[tarrencev]

Possible information + a schema off the top of my head is:

{
   worlds: [{
      "chain_id": "0x0",
      // Class has of the world contract
      "class_hash": "0x0",
      // address of the world contract
      "address": "0x0",
      "block_hash": "0x0",
      "block_number": "0x0",
      "transaction_hash": "0x0",
      "salt": "0x0",
   }]
}

Not all of that is strictly necessary, but might be useful to store rather than having to compute / derive the values

[lambda-0x]

currently schema is somewhat like this (have remove nested parts):

{
  "world": {
    "name": "$name",
    "address": "$ADDRESS",
    "class_hash": "$ADDRESS"
  },
  "executor": {
    "name": "$name",
    "address": "$ADDRESS",
    "class_hash": "$ADDRESS"
  },
  "systems": [
    {
      "name": "$name",
      "inputs": [],
      "outputs": [],
      "class_hash": "$ADDRESS",
      "dependencies": []
    }
  ],
  "contracts": [
    {
      "name": "$name",
      "class_hash": "$ADDRESS",
      "address": "$ADDRESS"
    }
  ],
  "components": [
    {
      "name": "$name",
      "members": [],
      "class_hash": "$ADDRESS"
    }
  ]
}

i think there was a PR on sozo allowing it to deploy multiple world contracts with name as seed but do we care about old world contract after new one is deployed? same question for executor can there be multiple executor deployed and do we need to store old one in manifest after new is deployed.

here is the struct that holds Manifest file currently:

dojo/crates/dojo-world/src/manifest.rs

Lines 88 to 94 in 778ca04

	pub struct Manifest {
	pub world: Contract,
	pub executor: Contract,
	pub systems: Vec<System>,
	pub contracts: Vec<Contract>,
	pub components: Vec<Component>,
	}

[lambda-0x]

also looks like here we are printing

🎉 Successfully migrated World at address {}

even when world contract itself is not migrated just one of the component is migrated, which is bit confusing. Should it be updated to display something like:

🎉 Successfully ran migration at block number {}

so @broody i am guessing what do want is block_number on which the last migration happened (even if it means only means one of the component was updated and not world contract)

nvm world contract is redeployed when there is atleast one change so current message makes sense.

[tarrencev]

currently schema is somewhat like this (have remove nested parts):
i think there was a PR on sozo allowing it to deploy multiple world contracts with name as seed but do we care about old world contract after new one is deployed? same question for executor can there be multiple executor deployed and do we need to store old one in manifest after new is deployed.

here is the struct that holds Manifest file currently:

dojo/crates/dojo-world/src/manifest.rs

Lines 88 to 94 in 778ca04

	pub struct Manifest {
	pub world: Contract,
	pub executor: Contract,
	pub systems: Vec<System>,
	pub contracts: Vec<Contract>,
	pub components: Vec<Component>,
	}

I think that is a good question. Should a manifest be per chain deployment? In that case, a manifest corresponds to a particular chain. That probably makes most sense? Then we can track a single deployment per manifest

[lambda-0x]

as discussed with @tarrencev manifest file related changes can be handled in a separate issue, will open one with more details.

I have clean up the linked PR for this issue and marked it for review.