mirror of
https://github.com/LaconicNetwork/laconic.com.git
synced 2026-09-08 11:14:09 +00:00
Get off DatoCMS (#135)
* Changes made to facilitate using local JSON files as a content source rather than dato cms Set follwoing variable in env to enable the changeover: NEXT_PUBLIC_DATOCMS_BYPASS_TYPE="local_json" Setting the above env variable to anything else will revert the site to pulling from datocms, assuming the account is still active with them. Look for any comment tagged with NEXT_PUBLIC_DATOCMS_BYPASS to see where the intercepts occur Signed-off-by: Traxus <shyidx@gmail.com> * update example ENV to include new variable for refrence Signed-off-by: Traxus <shyidx@gmail.com> * Fix Type error: 'getAllBlogPostsSlugs' is declared but its value is never read. Signed-off-by: Traxus <shyidx@gmail.com> * typescript test Signed-off-by: Traxus <shyidx@gmail.com> * primitive typescript appeasement vol 2 Signed-off-by: Traxus <shyidx@gmail.com> * ./src/lib/datocms-bypass.ts:72:6 Type error: Variable 'directories' implicitly has type 'any[]' in some locations where its type cannot be determined. Signed-off-by: Traxus <shyidx@gmail.com> * typescript appeasment vol 3 Signed-off-by: Traxus <shyidx@gmail.com> * typescript Signed-off-by: Traxus <shyidx@gmail.com> * typescript Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * lint Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * simple-import-sort, sorry. Signed-off-by: Traxus <shyidx@gmail.com> * Signed-off-by: Traxus <shyidx@gmail.com> * testing a blog post update * Trying to restore the lint command file Signed-off-by: Traxus <shyidx@gmail.com> * Remove Press Page Signed-off-by: Traxus <shyidx@gmail.com> * Hide Test Blog post Signed-off-by: Traxus <shyidx@gmail.com> * moved the copy of /press to /src/_old_pages/_press so that there would be a refrence copy but to keep the url inacessible to the public Signed-off-by: Traxus <shyidx@gmail.com> --------- Signed-off-by: Traxus <shyidx@gmail.com> Co-authored-by: Traxus <shyidx@gmail.com>
This commit is contained in:
Zach
Traxus
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,529 @@
|
||||
{
|
||||
"data": {
|
||||
"blogPost": {
|
||||
"author": {
|
||||
"id": "63992470",
|
||||
"name": "Zach Ramsay"
|
||||
},
|
||||
"category": [
|
||||
{
|
||||
"slug": "fake",
|
||||
"title": "Fake",
|
||||
"id": "6311820"
|
||||
}
|
||||
],
|
||||
"content": {
|
||||
"blocks": [
|
||||
{}
|
||||
],
|
||||
"links": [],
|
||||
"value": {
|
||||
"schema": "dast",
|
||||
"document": {
|
||||
"type": "root",
|
||||
"children": [
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Here’s the main problem: reading data from the Ethereum blockchains is either cheap and sloppy or expensive and correct. As a result, Dapp developers have come to rely on inexpensive centralized services that do not provide evidence to verify the correctness of the data they are serving to Dapps."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Not only is it expensive to get verifiable data but it can also be challenging to parse out the subset of data you really need. In the early days of SQL, you had to be proficient at the command line in order to use the product, and so use was limited to those that had that specialized capability."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Eventually, GUIs were built such that anyone with basic computer skills could use drop-down menus and create database schemas without writing a single line of code. Web3 is still in the early days of SQL, it is not easy onboarding new users and developers who are otherwise quite capable with the latest Web2 technologies.\n\nRight now, there’s all this data on Ethereum and as a Dapp developer, you only want a tiny fraction of it. But, to verify that fraction, you have to (among several other things) maintain an archive node - this is prohibitively expensive for the majority of developers. To solve this problem, centralized services such as (Infura, The Graph, and Alchemy) have popped up and currently account for the majority (if not most) of Dapp queries to Ethereum."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic was created to address these and several other problems in the blockchain ecosystem. Not only does Laconic make it easy to get verifiable data - quickly and cheaply - it also provides a framework for data transformation and aggregation that are difficult or impossible to do in other systems.\n\nArchitecting a solution to this requires many moving pieces; these have been developed by core Ethereum & Cosmos contributors over the past 5 years. In this post, we will walk you through the various components of the Laconic Stack."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There are three different ways to participate in the Laconic Network: Member Validators, Service Providers, and Dapp Developers. To describe the responsibilities and benefits of each role, we must first start grounded in the technicalities of the Laconic Stack."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Let’s take a look at the following core stack diagram:"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"item": "63992474",
|
||||
"type": "block"
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Note: this diagram intentionally leaves out several repositories (e.g., codecs, utilities, rpc shims). This is done for simplicity reasons and anyone diving deep into the stack will discover them.\n\nThe two repositories at the top are also the main entry points for most developers. `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/stack-orchestrator",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "stack-orchestrator"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` is a command-line tool for, well, orchestrating the stack. It uses docker-compose to deploy a specified collection of networked docker containers, thereby eliminating the need to set up a variety of services independently. Every user of the Laconic Stack will at some point - if not regularly - use the stack orchestrator."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/watcher-ts",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "watchers-ts"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` repo contains the publically available Watchers and the code to generate them. Watchers are TypeScript that is generated from one or more Solidity smart contracts. Dapp Developers can participate in the Laconic Network by either 1) writing a custom watcher for their Dapp or 2) writing a generally useful watcher and publishing it to the Laconic Registry, thus earning a fee every time it is used. We’ll come back to Watchers later."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Down at the bottom left is the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconicd",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconicd"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` repository and it is indeed the “bottom” of the stack. It is built from the Cosmos SDK and has custom modules specific to operating the Laconic Network (e.g., fork of Ethermint/Evmos, auction, nameservice). It is likely that in the future there will be a public testnet, however, because the Laconic Network is a permissioned validator set, only Member Validators that have officially joined the Laconic Network will be included in the mainnet. Just because the validator set is permissioned does not prohibit anyone from running a full node and Service Providers or others may choose to do so for a variety of reasons."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconic-sdk",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconic-sdk"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` is a library for facilitating talking to `laconicd`. Both the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconic-registry-cli",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconic-registry-cli"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` and the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconic-console",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconic-console"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` use it. While `laconic-registry-cli` is a command-line tool for doing so, the `laconic-console` is a user interface for writing and reading records on the Laconic Network. These general-purpose tools are useful for a wide variety of use cases across the stack."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "A key goal of the Laconic Network is to provide accurate, verifiable data from the Ethereum blockchain. Comparisons to currently available solutions are for another post, however, no service currently exists to provide inexpensive evidence that the data being served is correct. The Laconic solution (one of) to this is in something called “statediffing”, a part of the stack run by Member Validators and, likely by Service Providers."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "It starts with a maintained fork of `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/go-ethereum",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "go-ethereum (geth)"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` that has an added real-time state-diffing service. Statediffing gives a clear picture of the state between any given blockheights. This allows Laconic to minimize the amount of computation required for providing proofs. Three additional “helper” services perform different tasks required to get a full picture of the state as required by an application. Together, these comprise the Full Index Node (FIN)."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/eth-statediff-service",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "eth-statediff-service"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` provides historical state data, while the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/eth-statediff-fill-service",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "eth-statediff-fill-service"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` uses the historical state data to fill statediff gaps as required. Finally, the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/ipld-eth-state-snapshot",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "ipld-eth-state-snapshot"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` loads a complete state at a certain blockheight, which helps to bootstrap the system. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "\nThere is more to be written about statediffing, however, what’s important to note here is that each service is writing independently to `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/ipld-eth-db",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "ipld-eth-db"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "`. The latter serves as a bucket for state data that has been indexed in IPLD. Rather than querying this database directly, the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/ipld-eth-server",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "ipld-eth-server"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` provides an API layer for Watchers to easily query relevant pieces of data from the Ethereum state. Additionally, `ipld-eth-server` recapitulates the native Ethereum JSON RPC interfaces on top of the `ipld-eth-db` database."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "And so we’ve come full circle back to the Watchers. As previously mentioned, they are generated from one or more Solidity smart contracts and configured to query specific pieces of data relevant to a Dapp. Watchers make it easy to query the data you need from Ethereum "
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"emphasis"
|
||||
],
|
||||
"value": "and"
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": " - along the way - get evidence in order to generate proofs that your data is correct. This is in contrast to currently available solutions for Dapp developers, who must currently rely on centralized providers that don’t provide evidence to generate proofs."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Web3 is (still!) in its early days, and like the early days of SQL, Dapp developers need advanced knowledge of complex data structures to build their Dapp. Watchers simplify this by exposing a GraphQL endpoint, a solution familiar to an order of magnitude more developers than querying the Ethereum blockchain directly."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic is building a suite of tools to address core problems in Web3. Today, we’ve provided an overview of the main components of the Laconic Stack. Developers interested in Laconic should start with `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/stack-orchestrator",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "stack-orchestrator"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` to get a sense of running different parts of the stack, then check out `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/watcher-ts",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "watcher-ts"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` to experiment with different watchers and progress to making their own."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
"date": "1999-01-18",
|
||||
"featured": false,
|
||||
"id": "63992475",
|
||||
"image": {
|
||||
"url": "https://www.datocms-assets.com/66113/1673986992-laconic_clippy_grid2.png"
|
||||
},
|
||||
"slug": "copy-b",
|
||||
"title": "COPY B"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,389 @@
|
||||
{
|
||||
"data": {
|
||||
"blogPost": {
|
||||
"author": {
|
||||
"id": "55457832",
|
||||
"name": "Michael Gushansky"
|
||||
},
|
||||
"category": [
|
||||
{
|
||||
"slug": "insights",
|
||||
"title": "Insights",
|
||||
"id": "6311819"
|
||||
},
|
||||
{
|
||||
"slug": "fake",
|
||||
"title": "Fake",
|
||||
"id": "3545003"
|
||||
}
|
||||
],
|
||||
"content": {
|
||||
"blocks": [],
|
||||
"links": [],
|
||||
"value": {
|
||||
"schema": "dast",
|
||||
"document": {
|
||||
"type": "root",
|
||||
"children": [
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic cofounder Rick Dudley appeared on a special livestream of The Interop with host Sebastien Couture to discuss the Laconic Stack, the blockchain data problems that Laconic solves, Laconic’s novel governance structure, and how Laconic can index and verify data faster, more efficiently, and at lower cost. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Below is a distilled transcript of Rick’s responses during the discussion."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "The Future is App Chains"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "I think there will be millions of chains, and we'll be using a combination of rollups and mesh–not straight linear L1, L2, L3, but also meshes of rollups and attestations publishing bridges, etc. And although we may have millions of chains, we won't have millions of massive chains. A large chain may have 100 members, and there may be one or two chains out there with 4,000 validators. But in the world, you only need a few of those."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "I think everything becomes an app chain. I think mainnet Ethereum ultimately becomes an app chain and the application is settling rollups–very similar to Cosmos Hub, frankly. Polkadot, Ethereum 2.0, Cosmos Hub are all actually very similar in terms of the endgame state in the final thesis. And I don't think that there will necessarily be a winner per se. I think they will have curious different properties. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Why Laconic?"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The ultimate goal of Laconic is to get all of the data that a user is concerned about in the hands of that user. Not in a cloud-hosted environment, not in Microsoft, not in AWS, but in users’ actual custody. And to enable them to do all the verification themselves."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Right now, it’s very difficult to extract parts of data from the Ethereum Mainnet that are relevant for Dapp needs. It’s almost impossible to synchronize a Geth node in a reasonable amount of time."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There are multiple light client protocols that have come around to help alleviate this problem but they still don't go all the way. The Laconic Network goes the whole way. It goes from source code, to what is in the user's eyeballs with everything being verifiable. If you see a message on Laconic that came to you through the Laconic Network, you could say, \"I want to know which blockchain or blockchains this came from. I want to know what code generated this result. I want to know who wrote that code.” We provide all of that in the Laconic Network."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Three Major Components of Laconic"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There is the Laconic LLC itself, which is in the Cayman Islands. There is the Laconic Stack, which is the standalone software that anyone can run today to generate this data and the evidence that they need. And then there's the Laconic Network, which facilitates the buying and selling of data. It facilitates running these services, discovering the services, paying for services, and then making sure all of that is verifiable."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Those three components are an evolution. We've iterated on the Stack many times over at this point. MakerDAO is still using an early version of that stack to this day last I checked, which was recently. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "If you were an intrepid developer, you could go into the Stack Orchestrator code and run that yourself and put that into production yourself right now. But the problem with that is it's very expensive to generate this evidence. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "It’s computationally very expensive, and specifically, disk I/O operations are very expensive activities to do. So as a Dapp developer, when you have very few users, you can run this reasonably on the laptop. But as your app grows, or if you're wanting to see all of the Uniswap V3 pool data, then a laptop's not going to be able to process that in a timely manner necessarily. I mean, laptops are pretty powerful so some of them can, but maybe not all of them. And at that point, you need hardware. And when you need hardware, you then have this problem of, \"Okay, well am I going to buy hardware and rack it in a data center?\" That's probably not a viable answer."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Am I going to go to AWS? Well, AWS is centralized, there are all sorts of problems. There's censorship for instance. AWS may choose to comply with a law that I'm not legally obligated to comply with. We've seen this issue with Alchemy and Infura, and these solutions comply with the laws in their jurisdiction, but the Dapp developer is in a different jurisdiction. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "So then you end up with this situation; \"Okay, well if I want to have multiple service providers actually serving this data to users, they need to be in multiple jurisdictions.\" And that's what Laconic LLC solves. It's a Cayman Island LLC. We have members in different jurisdictions and those members will contract with the end users and comply with those laws in that way."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Laconic and Cosmos"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic team members were also core contributors to Cosmos SDK–we did a bunch of work on the Cosmos SDK. The data structures in Ethereum and the data structures in Cosmos and many other blockchains were designed to facilitate consensus, not to facilitate reading the data back out. And so in those architectures, there's utility in taking the techniques that we've applied to Ethereum and applying them to those other chains."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There is a value and utility to taking those techniques and applying them to the Cosmos SDK chains. Osmosis is an example of where it would be useful. For example, you can't have a block explorer that works across Cosmos Hub upgrades. No one's ever bothered to build one that works that way. If you built the block explorer on top of Laconic instead of directly on top of the chain, you would actually be able to provide that continuity."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Every time a Cosmos chain upgrades, they regenesis and restart the chain. When you start that new genesis, people–just as a matter of convenience–don't preserve that data. You don't have a way of representing the irregular state change that happens during the upgrade. Whereas in the Laconic system, we have a means of doing all those things. We can link any two arbitrary chains together and we have a means of representing these arbitrary state changes. We can provide that continuity as a service."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Incentive Alignment "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Because we're IPLD based, we actually can relatively easily take our archive and push it into Filecoin, where there can then be this clear monetization strategy for storing the data. Because we monetize the transmission of the data, which is a much easier problem to solve than the verifiable storage of Filecoin, we're providing an incentive for why someone would do that. Think about it. There are different incentives throughout the process. There's an incentive for including the transaction. That incentive is very clear, but there's not really any incentive in any blockchain I'm aware of for why I should then send that data. Why should I satisfy a read from a user? A user asks for a read, and why do I care?"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "That's what Laconic is trying to solve–we're incentivizing the reading of that data. And by incentivizing the reading of that data, that's step number two. Now we can talk about the incentives of step number three, which is a long-term persistent storage of that data. Because if you think about just having the incentives of just Filecoin and just Ethereum, you have this gap in the middle. Why do I take the Ethereum data and transform that and publish it to Filecoin? There's not really an incentive for me to do that."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Whereas with Laconic, there starts to become more of an incentive to do that because I need to support my own read infrastructure. People will come to you and know to come to a single place to get their historic reads as well as their more recent reads. And so you’ll be incentivized to charge them. There will already be an ecosystem in place where people are accustomed to paying for data. And when they want to pay for old data or new data, they'll come to the same place, buy that data, and that will incentivize archival storage. Right now we don't have a very good model for why archival storage persists. And it is a real mechanism design issue actually."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Laconic and IPLD"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "InterPlanetary Linked Data (IPLD) is the core of our system. The first thing we do is take the Ethereum data, which could be any blockchain or any hash linked data structure, and we convert that into an IPLD object. We then index it in that context. We’re storing the RLP encoded bytes, but we are also storing the CID (Content ID), the multi-format address of that object. That's how we're able to generate evidence."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "On Ethereum, you have transaction receipts and you have the event messages. When you have an event message on Ethereum, the event message does not prove all the way back up to the root. So when you have a set of events, which is what The Graph consumes, the way that you prove that event is correct is that you find the block that that event was in, and then you rerun that whole block and at the end of it you see if you have the same event that you started with. Whereas, if I have an account balance on Ethereum, I have a block number and then I can get a proof. So I don't have to recompute the whole block to figure out the account balance in that block. I just get the proof from the Ethereum client about that account balance at that block, and I can present that proof and the balance to the user using eth_getProof."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "But the actual logs in Ethereum are not provable in this way. This is why The Graph isn't provable and there are a lot of consequences from this. But because we use IPLD, we can create those hash links. Where the link was missing in the original Ethereum protocol, we can augment that protocol and generate a proof using the Ethereum data and our additional links, which are relatively easily. It's not some weird, crazy different format. It's this format that is very similar to the existing Ethereum formats, that prove that this log actually came from this block."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Laconic Member Validators"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic L2 has seven Founding Members right now. These seven Members validate, ingest the blocks, and make commitments to the state of those blocks. They then share that information with a paying customer. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There are plans to increase the validator set. From a customer perspective, if our customer is a Dapp developer and they're saying, “right now I have to use Infura, Alchemy, Blocknative to assert that my data is correct because if one of them goes down for whatever reason, that's three right there.” "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "That sounds like a pain in the ass. With Laconic, you integrate one protocol and you get seven Member Validators instead of three, and you get an assertion from us that you can verify yourself that we're actually physically located in different places. Alchemy and Infura both run in AWS, I presume. If AWS goes down, you just lost two out of your three, if not all three out of your three in that case. Seven is a low number, but seven is incredibly high compared to what people have right now, or they think they have four and they have one, whereas we're positively asserting that you have seven."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "RPC Services and Laconic"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "On the path to building Watchers, we realized we had to build extremely performant RPC endpoints, and we had to build out a deployment system. We realized that that was actually what people wanted to buy from us. Most Dapps don’t want to bother with Watchers right now. What they want to see is this immediate savings on the RPC endpoint side. From there, oncet our foot is in the door, we can say, \"Well, we can give you even more savings. You are using that RPC endpoint to build your own indexer. We have a whole library of tools to build indexers that will auto-generate indexers for you. And we have a marketplace where you can go to get other people to run that indexer for you when you don't want to scale it.\""
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Currently, RPC endpoints are subsidized by VCs. Dapp developers are never experiencing the true cost of running an indexing service or running an RPC endpoint. They're not exposed to that in a free market way. There's this actor, this venture capitalist, who is going in and giving away free samples at a massive scale. The challenge for us is in how we compete with that? There's also a challenge in that our customers are depending on this centralization service and don't realize it. "
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
"date": "2023-02-09",
|
||||
"featured": false,
|
||||
"id": "64080923",
|
||||
"image": {
|
||||
"url": "https://www.datocms-assets.com/66113/1675901476-laconic-seb-blog.png"
|
||||
},
|
||||
"slug": "copy-c",
|
||||
"title": "COPY C"
|
||||
}
|
||||
}
|
||||
}
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,529 @@
|
||||
{
|
||||
"data": {
|
||||
"blogPost": {
|
||||
"author": {
|
||||
"id": "63992470",
|
||||
"name": "Zach Ramsay"
|
||||
},
|
||||
"category": [
|
||||
{
|
||||
"slug": "developers",
|
||||
"title": "Developers",
|
||||
"id": "6311820"
|
||||
}
|
||||
],
|
||||
"content": {
|
||||
"blocks": [
|
||||
{}
|
||||
],
|
||||
"links": [],
|
||||
"value": {
|
||||
"schema": "dast",
|
||||
"document": {
|
||||
"type": "root",
|
||||
"children": [
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Here’s the main problem: reading data from the Ethereum blockchains is either cheap and sloppy or expensive and correct. As a result, Dapp developers have come to rely on inexpensive centralized services that do not provide evidence to verify the correctness of the data they are serving to Dapps."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Not only is it expensive to get verifiable data but it can also be challenging to parse out the subset of data you really need. In the early days of SQL, you had to be proficient at the command line in order to use the product, and so use was limited to those that had that specialized capability."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Eventually, GUIs were built such that anyone with basic computer skills could use drop-down menus and create database schemas without writing a single line of code. Web3 is still in the early days of SQL, it is not easy onboarding new users and developers who are otherwise quite capable with the latest Web2 technologies.\n\nRight now, there’s all this data on Ethereum and as a Dapp developer, you only want a tiny fraction of it. But, to verify that fraction, you have to (among several other things) maintain an archive node - this is prohibitively expensive for the majority of developers. To solve this problem, centralized services such as (Infura, The Graph, and Alchemy) have popped up and currently account for the majority (if not most) of Dapp queries to Ethereum."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic was created to address these and several other problems in the blockchain ecosystem. Not only does Laconic make it easy to get verifiable data - quickly and cheaply - it also provides a framework for data transformation and aggregation that are difficult or impossible to do in other systems.\n\nArchitecting a solution to this requires many moving pieces; these have been developed by core Ethereum & Cosmos contributors over the past 5 years. In this post, we will walk you through the various components of the Laconic Stack."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There are three different ways to participate in the Laconic Network: Member Validators, Service Providers, and Dapp Developers. To describe the responsibilities and benefits of each role, we must first start grounded in the technicalities of the Laconic Stack."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Let’s take a look at the following core stack diagram:"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"item": "63992474",
|
||||
"type": "block"
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Note: this diagram intentionally leaves out several repositories (e.g., codecs, utilities, rpc shims). This is done for simplicity reasons and anyone diving deep into the stack will discover them.\n\nThe two repositories at the top are also the main entry points for most developers. `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/stack-orchestrator",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "stack-orchestrator"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` is a command-line tool for, well, orchestrating the stack. It uses docker-compose to deploy a specified collection of networked docker containers, thereby eliminating the need to set up a variety of services independently. Every user of the Laconic Stack will at some point - if not regularly - use the stack orchestrator."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/watcher-ts",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "watchers-ts"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` repo contains the publically available Watchers and the code to generate them. Watchers are TypeScript that is generated from one or more Solidity smart contracts. Dapp Developers can participate in the Laconic Network by either 1) writing a custom watcher for their Dapp or 2) writing a generally useful watcher and publishing it to the Laconic Registry, thus earning a fee every time it is used. We’ll come back to Watchers later."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Down at the bottom left is the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconicd",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconicd"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` repository and it is indeed the “bottom” of the stack. It is built from the Cosmos SDK and has custom modules specific to operating the Laconic Network (e.g., fork of Ethermint/Evmos, auction, nameservice). It is likely that in the future there will be a public testnet, however, because the Laconic Network is a permissioned validator set, only Member Validators that have officially joined the Laconic Network will be included in the mainnet. Just because the validator set is permissioned does not prohibit anyone from running a full node and Service Providers or others may choose to do so for a variety of reasons."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconic-sdk",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconic-sdk"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` is a library for facilitating talking to `laconicd`. Both the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconic-registry-cli",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconic-registry-cli"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` and the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/laconic-console",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "laconic-console"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` use it. While `laconic-registry-cli` is a command-line tool for doing so, the `laconic-console` is a user interface for writing and reading records on the Laconic Network. These general-purpose tools are useful for a wide variety of use cases across the stack."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "A key goal of the Laconic Network is to provide accurate, verifiable data from the Ethereum blockchain. Comparisons to currently available solutions are for another post, however, no service currently exists to provide inexpensive evidence that the data being served is correct. The Laconic solution (one of) to this is in something called “statediffing”, a part of the stack run by Member Validators and, likely by Service Providers."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "It starts with a maintained fork of `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/go-ethereum",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "go-ethereum (geth)"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` that has an added real-time state-diffing service. Statediffing gives a clear picture of the state between any given blockheights. This allows Laconic to minimize the amount of computation required for providing proofs. Three additional “helper” services perform different tasks required to get a full picture of the state as required by an application. Together, these comprise the Full Index Node (FIN)."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/eth-statediff-service",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "eth-statediff-service"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` provides historical state data, while the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/eth-statediff-fill-service",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "eth-statediff-fill-service"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` uses the historical state data to fill statediff gaps as required. Finally, the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/ipld-eth-state-snapshot",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "ipld-eth-state-snapshot"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` loads a complete state at a certain blockheight, which helps to bootstrap the system. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "\nThere is more to be written about statediffing, however, what’s important to note here is that each service is writing independently to `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/ipld-eth-db",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "ipld-eth-db"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "`. The latter serves as a bucket for state data that has been indexed in IPLD. Rather than querying this database directly, the `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/ipld-eth-server",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "ipld-eth-server"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` provides an API layer for Watchers to easily query relevant pieces of data from the Ethereum state. Additionally, `ipld-eth-server` recapitulates the native Ethereum JSON RPC interfaces on top of the `ipld-eth-db` database."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "And so we’ve come full circle back to the Watchers. As previously mentioned, they are generated from one or more Solidity smart contracts and configured to query specific pieces of data relevant to a Dapp. Watchers make it easy to query the data you need from Ethereum "
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"emphasis"
|
||||
],
|
||||
"value": "and"
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": " - along the way - get evidence in order to generate proofs that your data is correct. This is in contrast to currently available solutions for Dapp developers, who must currently rely on centralized providers that don’t provide evidence to generate proofs."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Web3 is (still!) in its early days, and like the early days of SQL, Dapp developers need advanced knowledge of complex data structures to build their Dapp. Watchers simplify this by exposing a GraphQL endpoint, a solution familiar to an order of magnitude more developers than querying the Ethereum blockchain directly."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic is building a suite of tools to address core problems in Web3. Today, we’ve provided an overview of the main components of the Laconic Stack. Developers interested in Laconic should start with `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/stack-orchestrator",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "stack-orchestrator"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` to get a sense of running different parts of the stack, then check out `"
|
||||
},
|
||||
{
|
||||
"url": "https://github.com/cerc-io/watcher-ts",
|
||||
"meta": [
|
||||
{
|
||||
"id": "target",
|
||||
"value": "_blank"
|
||||
}
|
||||
],
|
||||
"type": "link",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"underline"
|
||||
],
|
||||
"value": "watcher-ts"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "span",
|
||||
"value": "` to experiment with different watchers and progress to making their own."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
"date": "2023-01-18",
|
||||
"featured": false,
|
||||
"id": "63992475",
|
||||
"image": {
|
||||
"url": "https://www.datocms-assets.com/66113/1673986992-laconic_clippy_grid2.png"
|
||||
},
|
||||
"slug": "intro-to-the-laconic-stack",
|
||||
"title": "[TEST EDIT TO LOCAL JSON] Intro to the Laconic Stack"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,389 @@
|
||||
{
|
||||
"data": {
|
||||
"blogPost": {
|
||||
"author": {
|
||||
"id": "55457832",
|
||||
"name": "Michael Gushansky"
|
||||
},
|
||||
"category": [
|
||||
{
|
||||
"slug": "insights",
|
||||
"title": "Insights",
|
||||
"id": "6311819"
|
||||
},
|
||||
{
|
||||
"slug": "product",
|
||||
"title": "Product",
|
||||
"id": "3545003"
|
||||
}
|
||||
],
|
||||
"content": {
|
||||
"blocks": [],
|
||||
"links": [],
|
||||
"value": {
|
||||
"schema": "dast",
|
||||
"document": {
|
||||
"type": "root",
|
||||
"children": [
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic cofounder Rick Dudley appeared on a special livestream of The Interop with host Sebastien Couture to discuss the Laconic Stack, the blockchain data problems that Laconic solves, Laconic’s novel governance structure, and how Laconic can index and verify data faster, more efficiently, and at lower cost. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Below is a distilled transcript of Rick’s responses during the discussion."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "The Future is App Chains"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "I think there will be millions of chains, and we'll be using a combination of rollups and mesh–not straight linear L1, L2, L3, but also meshes of rollups and attestations publishing bridges, etc. And although we may have millions of chains, we won't have millions of massive chains. A large chain may have 100 members, and there may be one or two chains out there with 4,000 validators. But in the world, you only need a few of those."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "I think everything becomes an app chain. I think mainnet Ethereum ultimately becomes an app chain and the application is settling rollups–very similar to Cosmos Hub, frankly. Polkadot, Ethereum 2.0, Cosmos Hub are all actually very similar in terms of the endgame state in the final thesis. And I don't think that there will necessarily be a winner per se. I think they will have curious different properties. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Why Laconic?"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "The ultimate goal of Laconic is to get all of the data that a user is concerned about in the hands of that user. Not in a cloud-hosted environment, not in Microsoft, not in AWS, but in users’ actual custody. And to enable them to do all the verification themselves."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Right now, it’s very difficult to extract parts of data from the Ethereum Mainnet that are relevant for Dapp needs. It’s almost impossible to synchronize a Geth node in a reasonable amount of time."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There are multiple light client protocols that have come around to help alleviate this problem but they still don't go all the way. The Laconic Network goes the whole way. It goes from source code, to what is in the user's eyeballs with everything being verifiable. If you see a message on Laconic that came to you through the Laconic Network, you could say, \"I want to know which blockchain or blockchains this came from. I want to know what code generated this result. I want to know who wrote that code.” We provide all of that in the Laconic Network."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Three Major Components of Laconic"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There is the Laconic LLC itself, which is in the Cayman Islands. There is the Laconic Stack, which is the standalone software that anyone can run today to generate this data and the evidence that they need. And then there's the Laconic Network, which facilitates the buying and selling of data. It facilitates running these services, discovering the services, paying for services, and then making sure all of that is verifiable."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Those three components are an evolution. We've iterated on the Stack many times over at this point. MakerDAO is still using an early version of that stack to this day last I checked, which was recently. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "If you were an intrepid developer, you could go into the Stack Orchestrator code and run that yourself and put that into production yourself right now. But the problem with that is it's very expensive to generate this evidence. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "It’s computationally very expensive, and specifically, disk I/O operations are very expensive activities to do. So as a Dapp developer, when you have very few users, you can run this reasonably on the laptop. But as your app grows, or if you're wanting to see all of the Uniswap V3 pool data, then a laptop's not going to be able to process that in a timely manner necessarily. I mean, laptops are pretty powerful so some of them can, but maybe not all of them. And at that point, you need hardware. And when you need hardware, you then have this problem of, \"Okay, well am I going to buy hardware and rack it in a data center?\" That's probably not a viable answer."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Am I going to go to AWS? Well, AWS is centralized, there are all sorts of problems. There's censorship for instance. AWS may choose to comply with a law that I'm not legally obligated to comply with. We've seen this issue with Alchemy and Infura, and these solutions comply with the laws in their jurisdiction, but the Dapp developer is in a different jurisdiction. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "So then you end up with this situation; \"Okay, well if I want to have multiple service providers actually serving this data to users, they need to be in multiple jurisdictions.\" And that's what Laconic LLC solves. It's a Cayman Island LLC. We have members in different jurisdictions and those members will contract with the end users and comply with those laws in that way."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Laconic and Cosmos"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic team members were also core contributors to Cosmos SDK–we did a bunch of work on the Cosmos SDK. The data structures in Ethereum and the data structures in Cosmos and many other blockchains were designed to facilitate consensus, not to facilitate reading the data back out. And so in those architectures, there's utility in taking the techniques that we've applied to Ethereum and applying them to those other chains."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There is a value and utility to taking those techniques and applying them to the Cosmos SDK chains. Osmosis is an example of where it would be useful. For example, you can't have a block explorer that works across Cosmos Hub upgrades. No one's ever bothered to build one that works that way. If you built the block explorer on top of Laconic instead of directly on top of the chain, you would actually be able to provide that continuity."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Every time a Cosmos chain upgrades, they regenesis and restart the chain. When you start that new genesis, people–just as a matter of convenience–don't preserve that data. You don't have a way of representing the irregular state change that happens during the upgrade. Whereas in the Laconic system, we have a means of doing all those things. We can link any two arbitrary chains together and we have a means of representing these arbitrary state changes. We can provide that continuity as a service."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Incentive Alignment "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Because we're IPLD based, we actually can relatively easily take our archive and push it into Filecoin, where there can then be this clear monetization strategy for storing the data. Because we monetize the transmission of the data, which is a much easier problem to solve than the verifiable storage of Filecoin, we're providing an incentive for why someone would do that. Think about it. There are different incentives throughout the process. There's an incentive for including the transaction. That incentive is very clear, but there's not really any incentive in any blockchain I'm aware of for why I should then send that data. Why should I satisfy a read from a user? A user asks for a read, and why do I care?"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "That's what Laconic is trying to solve–we're incentivizing the reading of that data. And by incentivizing the reading of that data, that's step number two. Now we can talk about the incentives of step number three, which is a long-term persistent storage of that data. Because if you think about just having the incentives of just Filecoin and just Ethereum, you have this gap in the middle. Why do I take the Ethereum data and transform that and publish it to Filecoin? There's not really an incentive for me to do that."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Whereas with Laconic, there starts to become more of an incentive to do that because I need to support my own read infrastructure. People will come to you and know to come to a single place to get their historic reads as well as their more recent reads. And so you’ll be incentivized to charge them. There will already be an ecosystem in place where people are accustomed to paying for data. And when they want to pay for old data or new data, they'll come to the same place, buy that data, and that will incentivize archival storage. Right now we don't have a very good model for why archival storage persists. And it is a real mechanism design issue actually."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Laconic and IPLD"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "InterPlanetary Linked Data (IPLD) is the core of our system. The first thing we do is take the Ethereum data, which could be any blockchain or any hash linked data structure, and we convert that into an IPLD object. We then index it in that context. We’re storing the RLP encoded bytes, but we are also storing the CID (Content ID), the multi-format address of that object. That's how we're able to generate evidence."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "On Ethereum, you have transaction receipts and you have the event messages. When you have an event message on Ethereum, the event message does not prove all the way back up to the root. So when you have a set of events, which is what The Graph consumes, the way that you prove that event is correct is that you find the block that that event was in, and then you rerun that whole block and at the end of it you see if you have the same event that you started with. Whereas, if I have an account balance on Ethereum, I have a block number and then I can get a proof. So I don't have to recompute the whole block to figure out the account balance in that block. I just get the proof from the Ethereum client about that account balance at that block, and I can present that proof and the balance to the user using eth_getProof."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "But the actual logs in Ethereum are not provable in this way. This is why The Graph isn't provable and there are a lot of consequences from this. But because we use IPLD, we can create those hash links. Where the link was missing in the original Ethereum protocol, we can augment that protocol and generate a proof using the Ethereum data and our additional links, which are relatively easily. It's not some weird, crazy different format. It's this format that is very similar to the existing Ethereum formats, that prove that this log actually came from this block."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "Laconic Member Validators"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Laconic L2 has seven Founding Members right now. These seven Members validate, ingest the blocks, and make commitments to the state of those blocks. They then share that information with a paying customer. "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "There are plans to increase the validator set. From a customer perspective, if our customer is a Dapp developer and they're saying, “right now I have to use Infura, Alchemy, Blocknative to assert that my data is correct because if one of them goes down for whatever reason, that's three right there.” "
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "That sounds like a pain in the ass. With Laconic, you integrate one protocol and you get seven Member Validators instead of three, and you get an assertion from us that you can verify yourself that we're actually physically located in different places. Alchemy and Infura both run in AWS, I presume. If AWS goes down, you just lost two out of your three, if not all three out of your three in that case. Seven is a low number, but seven is incredibly high compared to what people have right now, or they think they have four and they have one, whereas we're positively asserting that you have seven."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "heading",
|
||||
"level": 3,
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"marks": [
|
||||
"strong"
|
||||
],
|
||||
"value": "RPC Services and Laconic"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "On the path to building Watchers, we realized we had to build extremely performant RPC endpoints, and we had to build out a deployment system. We realized that that was actually what people wanted to buy from us. Most Dapps don’t want to bother with Watchers right now. What they want to see is this immediate savings on the RPC endpoint side. From there, oncet our foot is in the door, we can say, \"Well, we can give you even more savings. You are using that RPC endpoint to build your own indexer. We have a whole library of tools to build indexers that will auto-generate indexers for you. And we have a marketplace where you can go to get other people to run that indexer for you when you don't want to scale it.\""
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "paragraph",
|
||||
"children": [
|
||||
{
|
||||
"type": "span",
|
||||
"value": "Currently, RPC endpoints are subsidized by VCs. Dapp developers are never experiencing the true cost of running an indexing service or running an RPC endpoint. They're not exposed to that in a free market way. There's this actor, this venture capitalist, who is going in and giving away free samples at a massive scale. The challenge for us is in how we compete with that? There's also a challenge in that our customers are depending on this centralization service and don't realize it. "
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
"date": "2023-02-09",
|
||||
"featured": false,
|
||||
"id": "64080923",
|
||||
"image": {
|
||||
"url": "https://www.datocms-assets.com/66113/1675901476-laconic-seb-blog.png"
|
||||
},
|
||||
"slug": "rick-dudley-on-the-interop",
|
||||
"title": "[TEST EDIT TO LOCAL JSON] Rick Dudley Discusses Laconic Network on The Interop"
|
||||
}
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user