{"id":22998445,"url":"https://github.com/tablelandnetwork/dimo-vehicle-defs","last_synced_at":"2025-04-02T13:24:38.466Z","repository":{"id":187809122,"uuid":"677568917","full_name":"tablelandnetwork/dimo-vehicle-defs","owner":"tablelandnetwork","description":"Tableland-based DIMO Vehicle Definitions demo","archived":false,"fork":false,"pushed_at":"2023-08-16T20:34:35.000Z","size":4677,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-03-25T17:03:25.480Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"unlicense","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tablelandnetwork.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2023-08-11T23:31:19.000Z","updated_at":"2023-08-15T17:45:26.000Z","dependencies_parsed_at":null,"dependency_job_id":"7259d6be-2b7b-4b36-8f48-51dd0f1a831c","html_url":"https://github.com/tablelandnetwork/dimo-vehicle-defs","commit_stats":null,"previous_names":["tablelandnetwork/dimo-vehicle-defs"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tablelandnetwork%2Fdimo-vehicle-defs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tablelandnetwork%2Fdimo-vehicle-defs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tablelandnetwork%2Fdimo-vehicle-defs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tablelandnetwork%2Fdimo-vehicle-defs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tablelandnetwork","download_url":"https://codeload.github.com/tablelandnetwork/dimo-vehicle-defs/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246821053,"owners_count":20839350,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-15T06:13:26.551Z","updated_at":"2025-04-02T13:24:38.442Z","avatar_url":"https://github.com/tablelandnetwork.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# dimo-vehicle-defs\n\n[![standard-readme compliant](https://img.shields.io/badge/standard--readme-OK-green.svg)](https://github.com/RichardLitt/standard-readme)\n[![Test](https://github.com/tablelandnetwork/dimo-vehicle-defs/actions/workflows/test.yml/badge.svg?branch=main)](https://github.com/tablelandnetwork/dimo-vehicle-defs/actions/workflows/test.yml)\n\n\u003e Tableland-based DIMO Vehicle Definitions demo\n\n# Table of Contents\n\n- [Background](#background)\n- [Development](#development)\n- [License](#license)\n\n# Background\n\nThis is a demo of hosting the DIMO vehicle definitions table from the DIMO `VehicleId` ERC721 contract using Tableland. The table is owned by and written to by the `VehicleId` contract. `VehicleId` tokens represent user vehicles and are associated with a vehicle definition (e.g. 2011 Toyota Tacoma). The crux of the problem is how to ensure that a given vehicle definition exists when a new `VehicleId` is minted from the contract.\n\nWe show two potential solutions:\n\n1. [`VehicleId`](./contracts/VehicleId.sol) simply increments a counter whenever a new vehicle definition is added. When minting a `VehicleId`, the user passes in an integer that represents the Tableland row ID (auto-incrementing primary key) of a vehicle definition. Since table rows cannot be deleted, if this integer is greater than the current counter, we know it’s invalid and the transaction is rejected.\n2. [`VehicleId2`](./contracts/VehicleId2.sol) leverages a (somewhat experimental) on-chain [dynamic merkle tree](https://ethresear.ch/t/efficient-on-chain-dynamic-merkle-tree/11054) to track a root hash that represents the entire off-chain vehicle definitions table. When minting a `VehicleId`, the user passes in the Tableland row ID (auto-incrementing primary key) of a vehicle definition, a hash of its values (make, model, year, etc.), and a merkle inclusion proof that it actually exists in the off-chain table. The contract only needs to store a single `bytes32` representing the root hash. This approach is more heavy-handed, but ensures a tighter coupling between the `VehicleId` and vehicle definition.\n\n   Note that the proofs needs to be generated off-chain from the table state. Ideally, validators [`go-tableland`](https://github.com/tablelandnetwork/go-tableland) should have an API endpoint that allows users and apps to fetch inclusion proofs for a given row by internally maintaining a merkle tree for the table. As a user, you wouldn't have to trust what the validator gives you because verification happens on-chain against a root hash that is dynamically updated when rows are added/updated (remember, in this case the table can only be written to by the contract).\n\n## NFT Metadata\n\nWe also show how the ERC721 token metadata could be handled dynamically from the vehicle definitions table. The [tokenUri](./contracts/VehicleId.sol#L165) method returns a Tableland query that selects from the table using the internal VehicleId to vehicle definition mapping (see the query [here](./helpers/uris.ts#L19)). The result is that we get token metadata that can change based on its associated vehicle definition. Note, this is only implemented for [`VehicleId`](./contracts/VehicleId.sol).\n\nHere's what the metadata for a `VehicleId` might look like.\n\n```json\n{\n  \"name\": \"VehicleId #1\",\n  \"attributes\": [\n    {\n      \"trait_type\": \"device_type_id\",\n      \"value\": \"vehicle\"\n    },\n    {\n      \"trait_type\": \"make\",\n      \"value\": \"Ford\"\n    },\n    {\n      \"trait_type\": \"make_token_id\",\n      \"value\": 41,\n      \"display_type\": \"number\"\n    },\n    {\n      \"trait_type\": \"oem_platform_name\",\n      \"value\": \"FordPass\"\n    },\n    {\n      \"trait_type\": \"model\",\n      \"value\": \"F-250 Super Duty\"\n    },\n    {\n      \"trait_type\": \"year\",\n      \"value\": 2018,\n      \"display_type\": \"number\"\n    },\n    {\n      \"trait_type\": \"model_style\",\n      \"value\": \"King Ranch 4dr Crew Cab SB (6.2L 8cyl 6A)\"\n    },\n    {\n      \"trait_type\": \"model_sub_style\",\n      \"value\": \"King Ranch\"\n    }\n  ],\n  \"metadata\": {\n    \"vehicle_info\": {\n      \"base_msrp\": \"44600\",\n      \"fuel_type\": \"Diesel\",\n      \"wheelbase\": \"164 WB\",\n      \"generation\": \"13\",\n      \"driven_wheels\": \"4x4\",\n      \"number_of_doors\": \"4\",\n      \"manufacturer_code\": \"W2B\",\n      \"fuel_tank_capacity_gal\": \"34\"\n    }\n  }\n}\n```\n\nThere's a lot we could do with the metadata structure. We could `JOIN` from other tables, remove/add attributes, add an image/animation, etc. Note, because [most common metadata format](https://docs.opensea.io/docs/metadata-standards) doesn't support nested object traits in `attributes`, we just add the `metadata` column from the vehicle definitions table as a top level property.\n\n# Development\n\n## Building the client\n\nYou can build the Typescript client locally:\n\n```shell\nnpm install\nnpm run build\n```\n\n## Testing\n\nRun the test suite:\n\n```shell\nnpm test\n```\n\n## Deploying\n\nDeployments are handled on a per-network basis:\n\n```shell\nnpx hardhat run scripts/deploy.ts --network polygon\n```\n\n## Extracting the ABI and Bytecode\n\nYou can grab the assets you need by compiling and then using some `jq` magic:\n\n### ABI\n\n```shell\ncat artifacts/contracts/VehicleId.sol/VehicleId.json | jq '.abi' \u003e abi.json\n```\n\n### Bytecode\n\n```shell\ncat artifacts/contracts/VehicleId.sol/VehicleId.json | jq -r '.bytecode' \u003e bytecode.bin\n```\n\n### Generate the Go client!\n\nYou can use the above `abi.json` to build the Go client:\n\n```shell\nmkdir gobuild\nabigen --abi ./abi.json --bin ./bytecode.bin --pkg contracts --out gobuild/VehicleId.go\n```\n\n## Etherscan verification\n\nTo perform Etherscan verification, you first need to deploy a contract to an Ethereum network that's supported by Etherscan, such as Polygon:\n\n```shell\nnpx hardhat run scripts/deploy.ts --network polygon\n```\n\nThen, add a `POLYSCAN_API_KEY` to your `.env` file and run the verify script:\n\n```shell\nnpx hardhat run scripts/verify.ts --network polygon\n```\n\n## Speedier tests\n\nFor faster runs of your tests and scripts, consider skipping ts-node's type checking by setting the environment variable `TS_NODE_TRANSPILE_ONLY` to `1` in hardhat's environment. For more details see [the documentation](https://hardhat.org/guides/typescript.html#performance-optimizations).\n\n# License\n\n[The Unlicense](LICENSE)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftablelandnetwork%2Fdimo-vehicle-defs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftablelandnetwork%2Fdimo-vehicle-defs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftablelandnetwork%2Fdimo-vehicle-defs/lists"}