))` |
-| 获取json对象的差异
| ("takerOutputUpdate"->
'deltaWei'->'value')
decode(substring(("addressSet"->'baseAsset')::TEXT, 4,40), 'hex')
| get_json_object(get_json_object(takerOutputUpdate,'$.deltaWei'),'$.value')
'0x'
|
-
-如果你发现任何其他需要注意的重要更改，请随时向我们的文档提交 PR 或在 [Discord](https://discord.com/dunecom) 中给我们反馈！
-
-在搜索 SQL 问题时，你现在应该搜索 `Databricks SQL median`，而不是搜索 `PGSQL median`。Databricks 在其网站上有一个有据可查的内置函数索引。
+| **bytea2numeric does not exist in Spark.** | bytea2numeric(bytea) | cast(CONV(string, 16, 10) as decimal) |
+| **0 vs 1 based indexing** | 1 indexed | 0 indexed |
+| **bytea vs string for address, tx hash, etc…** | \x2a7d..
(bytea)
| 0x2a7d...
(string)
|
+| **Addresses (strings) are lower case in dune v2** | \x2A7D...(bytea)
Works in Postgres
| 0x2a7d... (string)
Has to be lowercase in Spark.
Can be done via lower('0x2A7D...').
|
+| **Selecting keyword columns is is different** | `"from"` | `` `from` `` |
+| **Alias naming is different** | `as "daily active users`" | ``as `daily active user``\` |
+| **Exponentiation notation** | `x/10^y` | `x*power(10,y)` or `x*1e*y` |
+| **Interval arguments need a space in between the number and time units** | `Interval '1day'` | `Interval '1 day'` |
+| **Generate\_series () is now sequence ()** | `generate_series('2022-05-15', CURRENT_DATE, '1 day')` | `explode(sequence(to_date('2022-01-01'), to_date('2022-02-01'), interval 1 day))` |
+| **Decimals are no longer in prices.usd** | Don’t use
prices.usd decimals
| Replace by `blockchain.erc20_tokens.decimals` |
+| **Define NULL array** | `NULL::integer[]` | `CAST(NULL AS ARRAY))` |
+| Get json object
differences
| ("takerOutputUpdate"->
'deltaWei'->'value')
decode(substring(("addressSet"->'baseAsset')::TEXT, 4,40), 'hex')
| get_json_object(get_json_object(takerOutputUpdate,'$.deltaWei'),'$.value')
'0x'
|
-{% embed url="https://docs.databricks.com/sql/language-manual/sql-ref-functions-builtin.html" %}
+If you have found any other changes that are important to note, please feel free to sumbit a PR to our docs or leave us feedback in Discord!
-### 数据库工作方式的变化
+If you have found any other changes that are important to note, please feel free to sumbit a PR to our docs or leave us feedback in [Discord](https://discord.com/dunecom)!
-**数据库是如何工作的？**
+When googling for SQL questions, instead of googling `PGSQL median`, you should now google for `Databricks SQL median`. Databricks has a well documented index of built in functions on their website.
-在非常高的层次上，数据库将数据从存储读取到内存中，以返回你的查询结果。数据库通常会受到其将数据读入内存的速度的限制。这是一个经典的计算机科学问题，通常被称为 [I/O 边界](https://en.wikipedia.org/wiki/I/O\_bound)。
+{% embed url="https://docs.databricks.com/sql/language-manual/sql-ref-functions-builtin.html" %}
-#### **面向行的数据库**
+### Changes in how the database works
-数据库将其数据存储在页（pages）中。页通常包含多行信息。多页将组成一个数据文件。数据库中的一个表有时会包含多个数据文件。
+**How does a database work?**
-.png>)
+On a very high level, databases read data from storage into memory in order to return your query results. A database is often times limited by the speed of the database being able to read data into it's memory. This is a classic computer science problem that's commonly referred to as being[ I/O bound](https://en.wikipedia.org/wiki/I/O\_bound).
-当从数据库中检索数据时，数据库会按页（page）的大小将数据读入内存/缓存中。这是数据库一次读取的最小数据量，也是从任何数据库读取数据时的常见瓶颈所在。将数据读入内存后，数据库要么创建临时文件，要么能够再次从内存中读取数据，最终到达所需的查询输出。
+#### **Row oriented database**
-在任何数据库系统中，我们都希望在从数据库中检索任意数量的数据时减少读取的页的数量。由于传统数据库将多行数据存储在一页中，因此它们最适合在一个查询中检索一行的所有列的情况。数据库将始终必须读取存储特定行的整个页，因此数据库返回也存储在同一页中的其他数据非常简单。查询在数据库中紧密存储在一起的其他行也是如此。因此查询第 500-600 行是非常高效的，查询第 5、87、789 和 1050 行并不是那么高效，但仍然没问题。
+Databases store their data in pages. Pages traditionally contain rows of information. Multiple pages will make up one datafile. A table in a database will sometimes consist of multiple datafiles.
-与此相反，查询存储在许多不同逻辑行和不同页中的数据是一项非常昂贵的操作。我们今天在 Dune 上运行的大多数查询都是来自跨越数千行甚至数百万行记录中的某一列的数据点的聚合。在这些情况下，数据库将读取存储此列数据的整个页，即使它只需要其中一列的数据。这意味着平均而言，我们正在读取大量返回查询结果并不需要用到的数据，只是因为它也包含在同一个页上，并且数据库不能“仅”读取一列，而是必须读取包含该列的整行。
+.png>)
-在 Postgres 中，我们可以使用索引来避免强制数据库读取整个表（因此读取很多页），而只查看其中一个结构化的子集。这将导致非常快速和高效的查询，但仅限于被索引的列。由于为特定表创建的每个新索引都将是数据库中的一个新文件，并且使更新和维护该表变得更加困难，因此这并不是扩展数据库的可持续方法。
+When retrieving data from the database, the database will read data into memory/cache in the size of pages. This is the smallest amount of data the database will read at once and is a common bottleneck while reading data from any database. After reading the data into memory, the database will either create temporary files or is able to read the data from memory again to finally arrive at the desired query output.
-我们不可能在数据库中的每一列或列组合上创建索引而不会遇到麻烦。因此，Dune V2 不会在面向行的数据库上运行，而是在面向列的数据库上运行。
+In any database system, we want to reduce the amount of pages we read when retrieving any amount of data from the database. Since traditional databases store rows in one page, they are best suited for retrieving all columns of one row in a query. The database will always have to read the entire page in which a specific row is stored, therefore it is quite simple for the database to return the data also stored in this same page. The same is true for querying for rows which are stored closely together in the database. So querying for rows 500-600 is very efficient, querying for rows 5, 87, 789 and 1050 is not really all that efficient, but still alright.\
+In contrast, querying for data which is stored in many different logical rows and therefore different pages is a hugely expensive operation. Most of the queries we run on Dune today are aggregation of datapoints in a column over thousands if not millions of rows. In these cases, the database will read the entire pages in which this column data is stored, even though it only needs the data of one column. This means that on average, we are reading large amounts of data that is not needed to return the query results, just because it is also contained on a page and the database is not able to read "just" the one column, but has to read the entire row in which the column is contained.
-#### **面向列的数据库**
+In Postgres, we can use indexes to not force the database to read through the entire table (and therefore a lot of pages), but rather only look at a structured subset. This will lead to very fast and efficient queries, but is limited to the columns which are indexed. Since every new index that is created for a specific table will be a new file in the database and make it harder to update and maintain that table, this is not a sustainable approach to scale a database.\
+We can't possibly create an index on every column or combination of columns in our database without running into trouble down the line. Therefore, Dune V2 will not run on row-oriented database, but rather on a column-oriented database.
-我们不是在页中存储行，而是在页中存储列。通过这种方式，我们减少了数据库在聚合或读取特定列时需要读取的页数量。
+#### **Column oriented database**
-
+Instead of storing rows in pages, we store columns in pages. In this way, we reduce the amount of pages the database needs to read while aggregating or reading through a specific column.
-具体来说，在 Dune V2 中，我们将 [parquet 文件格式](https://github.com/apache/parquet-format) 用于我们的新数据库。Parquet 有时被描述为面向行的数据库和面向列的数据库之间的混合方法，因为数据库中的表仍然由多个 Parquet 文件组成，这些文件由数据集的行分区。在 parquet 文件中，实际包含数据的页将包含列而不是行，但仍存储在行组中，这些行组进一步按行划分数据。数据库仍然粗略地以面向行的格式存储，但各个值以列方向存储在页上。
+
-
+Specifically, in Dune V2 we are using the [parquet file format](https://github.com/apache/parquet-format) for our new database. Parquet is sometimes described as a hybrid approach between row-oriented databases and column-oriented databases since a table in the database will still consist of multiple parquet files which are partitioned by rows of the dataset. Inside of the parquet file the pages which actually contain the data will contain columns instead of rows, but are still stored within row groups which further partition the data by rows. The database is still roughly stored in a row oriented format, but the individual values are stored on pages in column orientation.
-这意味着，即使整个数据库在某种程度上是以面向行的方式定向的，但如果我们真的想要读取数据，我们总是会从面向列的页中读取。通过这种方式，我们可以轻松地将大量逻辑行中的数据聚合到一列中，因为在这种布局中，我们必须加载到内存中以实际读取数据的页的数量被最小化了。
+
-相反，如果我们尝试查询特定逻辑行的所有列，我们必须访问许多不同的页，因为一个逻辑行的数据不再存储在一个页中，而是分布在许多不同的页中。
+\
+This means, that even though the database at large is somewhat oriented in a row oriented manner, should we actually want to read data, we will always read from a page which is column oriented. In this way, we can easily aggregate data in one column over a large amounts of logical rows, as in this layout the amount of pages we have to load into memory to actually read the data is minimized.\
+In contrast, should we try to query for all columns of specific logical rows, we have to access lots of different pages as the data of one logical row is no longer stored in one page, but rather distributed across lots of different pages.
-这个视频很好地解释了面向行和面向列的数据库系统的差异。
+This video does a pretty good job of explaining the differences in row vs column oriented database systems.
{% embed url="https://youtu.be/Vw1fCeD06YI" %}
-**本质上**，将列而不是行存储在页中可以最大限度地减少数据库在从大量逻辑行中检索一列的数据时读取的不需要的数据量。我们有时能够在 Postgres 中通过以索引的形式创建大量结构化的子集数据来模仿这一点，但这并不能扩展。
-
-### 索引或者干脆没有索引
+**In essence**, storing columns in pages instead of rows minimizes the amount of not needed data that is read by the database when retrieving data for one column over a large amount of logical rows. We were sometimes able to mimic this in Postgres by creating large amounts of structured subset data in the form of indexes, but this doesn't scale.
-在基于 parquet 的系统中，传统意义上的索引并不存在。但是，它们基本上是动态创建的，每个 parquet 文件都有一个页脚，其中包含存储在该 parquet 文件中的每一列的`最小/最大`值。然后在列块级别上重复此模式，它为 parquet 文件中特定行组内的不同列存储此元数据。
+### Indexes or rather no Indexes
-
+Indexes don't exist in a traditional sense in a parquet based system. However, they are basically created on the fly with each parquet file having a footer that contains `min/max` values for every column stored in that parquet file. This pattern is then repeated on a column chunk level, which stores this metadata for the columns within a specific row group within the parquet file.
-在文件级别和列块级别同时使用这些 `最小/最大` 值，允许数据库在扫描表时高效地跳过整个 parquet 文件或 parquet 文件中的列块。
+
-不幸的是，字符串的 `最小/最大` 值通常不是很有用。特别是区块链系统中的 `tx_hash` 字符串和 `address` 字符串不适合这种 `最小/最大` 数据收集，因为它们是随机生成的。这意味着数据库将无法基于这些字符串跳过文件或列块，因此查询将非常低效，因为它需要数据库实际将所有页加载到内存中。
+Using these `min/max` values, both on a file level and on a column chunk level, allows the database to efficiently skip over entire parquet files or column chunks within parquet files while scanning through the table.
-也就是说，由于整个查询引擎仍然能够非常有效地读取存储这些字符串的各个列，因此大多数情况下这不会对你的查询执行速度产生很大影响。
+Unfortunately, the `min/max` values of strings are often times not very useful. Especially `tx_hash` strings and `address` strings in blockchain systems are not suited well for this kind of `min/max` data gathering since they are randomly generated. That means the database won't be able to skip files or column chunks based on these strings and queries will therefore be quite inefficient since it requires the database to actually load all the pages into memory.\
+That said, since the query engine at large is still able to read through individual columns in which these strings are stored very efficiently, most of the time this won't make a big difference in your query execution speed.\
+This is mostly relevant for base tables like `ethereum.transactions`, `bnb.logs`, `erc20_ethereum.erc20_evt_transfer`, etc. which contain very large datasets which are not prefiltered.
-这主要与 `ethereum.transactions`、`bnb.logs`、`erc20_ethereum.erc20_evt_transfer` 等基表相关，这些基表包含未经预过滤的非常大的数据集。
+A noteable exception from this is the solana dataset `account_activity`_,_ which instead of being ordered by `block_time` like the rest of our datasets, is ordered by `account_keys`. This allows us to actually reasonably utilize the `min/max` values for the account keys which were used and therefore run efficient queries based on the `account_keys` values.
-一个值得注意的例外是 solana 数据集 `account_activity` ，它不像我们的其他数据集那样按 `block_time` 排序，而是按 `account_keys` 排序。这使我们能够实际合理地利用所使用的帐户密钥的 `最小/最大` 值，从而基于 `account_keys` 值运行有效的查询。
+### Query examples
-### 查询示例
+Equipped with this knowledge, let's look at some queries on the new Dune V2 engine.
-有了这些知识，我们再来看看新版 Dune V2 引擎的一些查询。
-
-**查询交易哈希**
+**Querying for transaction hashes**
```sql
Select * from ethereum.transactions
where hash = '0xce1f1a2dd0c10fcf9385d14bc92c686c210e4accf00a3fe7ec2b5db7a5499cff'
```
-如果使用我们之前学到的所有知识再次考虑这一点，希望你能明白此查询非常低效。我们这里唯一的过滤条件是 `hash` 字符串，因此我们基本上强制查询引擎读取所有存储 `tx_hash` 列数据的页。我们可能可以跳过那些存储在每个 parquet 文件的页脚中的最小/最大值是 `0xa0 - 0xcd` 的部分列块，但这些只是一个罕见的例外。
-
-鉴于我们在搜索一个 `哈希` 时基本上对以太坊主网的整个历史进行了全面扫描（在撰写本文时为 1.6b 个条目），这个查询在大约 6 分钟内运行完成是相当令人印象深刻的。
+If you think about this for second with all the knowledge we have learned earlier, you will hopefully understand that this query is very inefficient. Our only filter condition here is a `hash` string, therefore we basically force the query engine to read all pages which store the data of the `tx_hash` column in full. We probably can skip a few column chunks where the min/max value stored in the footer of each parquet file is `0xa0 - 0xcd`, but those will be a rare exception. \
+Given that we are basically doing a full scan over the entire history of Ethereum mainnet (1.6b entries at time of writing) while searching for one `hash`, it's pretty impressive that this query runs in about 6 minutes.
-鉴于查询 `哈希` 是 Dune 分析师工作流程中非常常见的情况，让我们考虑一下如何才能更快地完成这项工作。
+Given that querying for `hash` is a very common occurence in the workflow of an analyst on Dune, let's think about how we can make this faster.
-我们只需要使用一个实际上包含有用的 `最小/最大` 值的列，以便能够不必完整读取所有页，而是能够跳过大量文件和列块。`block_time` 和 `block_number` 都可用于此目的。
+We simply have to use a column that actually has useful `min/max` values in order to be able to not read all pages in full, but rather be able to skip over a lot of files and column chunks. Both `block_time` and `block_number` are useful for this purpose.
```sql
Select * from ethereum.transactions
@@ -116,28 +113,27 @@ where block_number = 14854616
and hash = '0xce1f1a2dd0c10fcf9385d14bc92c686c210e4accf00a3fe7ec2b5db7a5499cff'
```
-这个查询仍然不如在 Postgres 中那么快（在Postgres中我们可以使用 btree 索引），但运行时间为 13 秒，我们已经非常接近了。
-
-在这种情况下，查询执行期间发生的情况是，数据库引擎能够读取 parquet 文件的页脚，能够确定许多 parquet 文件的 `最小/最大` 值不符合定义的标准，并且有效地跳过它们。一旦我们找到了一个真正满足我们条件的 parquet 文件，我们可以简单地深入到列块的 `最小/最大` 值，找到正确的列块，将剩下的几页列数据加载到内存中，然后找到也匹配“ `哈希` 条件的部分。由于我们从这个查询中的逻辑行中选择所有条目，我们实际上还需要访问一些其他页，但如果我们只对几行执行此操作，这是一个相当有效的操作。
+This query is still not as fast as in Postgres, where we can make use of btree indexes, but with a runtime of 13 seconds, we are getting pretty close.\
+What happens during the query execution in this case is that the database engine is able to read the footer of the parquet files, is able to determine that the `min/max` values of a lot of parquet files is not meeting the defined criteria and skip over them efficiently. Once we have found a parquet file that actually meets our conditions, we can simply drill down into the column chunk `min/max` values, find the right column chunks, load the few pages of column data that are left into memory and find the match for the `hash` condition as well. Since we are selecting all entries from the logical row in this query, we actually need to access a few other pages as well, but this is a reasonably efficient operation if we only do this for a few rows.
-**经验：** 以数据库能够合理使用文件和列块的 `最小/最大` 值的方式定义你的条件，以便它可以高效地找到你需要的逻辑行。
+**Lesson:** Define your conditions in a way in which the database is able to reasonably work with `min/max` values of files and columns chunks so it can efficiently find the logical row you need.
-**在大量逻辑行上聚合数据**
+**Aggregating data over a large amount of logical rows**
-这主要是一个案例研究，以说明 Dune V2 在通过大量逻辑行聚合数据方面的效率。
+This is mainly a case study to illustrate how efficient DuneV2 is in aggregating data over a large set of logical rows.
```sql
Select avg(gas_used) from ethereum.transactions
```
-此查询在 **惊人的** 7 秒内运行完成。这主要是因为我们现在不必从字面上读取整个表。我们现在能够大大减少必须读取的页数量，因为所有这些数据都存储在多个 parquet 文件中的页中。在 Postgres 中，我们必须读取的每个页都包含大量不需要的数据，在 Dune V2 中，我们只读取我们实际需要的数据。
+This query runs in an **amazing** 7 seconds. This is mainly due to the fact that instead of having to read literally the entire table, we are now able to able to majorly reduce the amount of pages we have to read, since all this data is stored together in pages across parquet files. In Postgres, each page that we would have to read would have contained a lot of not needed data, in Dune V2, we just read the data that we actually need.
-**经验：** 跨大量逻辑行查询数据现在更加高效，并且许多以前由于超时而完全不可能的查询现在已经可以正常执行。
+**Lesson:** Querying for data across a large amount of logical rows is now much more efficient and a lot of queries that were formerly sheer impossible due to timing out are now able to be executed.
-[hildobby 的](https://twitter.com/hildobby\_) [Ethereum 概述](https://dune.com/hildobby/Ethereum-Overview) 仪表盘就是一个很好的例子来说明这一点。这是以前根本无法实现的数据处理级别。
+A good example to illustrate this is [hildobby's](https://twitter.com/hildobby\_) [Ethereum Overview](https://dune.com/hildobby/Ethereum-Overview) dashboard. This is simply a level of data processing that was not possible before.
-### 结束语
+### Closing remarks
-一些在我们的 v1 数据库中被大量索引的查询在 DuneV2 中可能会感觉有点尴尬。对于 erc20 事件转移表(event transfer)、`ethereum.transactions` 和 `ethereum.logs` 以及它们在其他区块链上的对应物来说尤其如此。这是我们愿意为大规模启用区块链分析而做出的权衡。我们将继续对这些数据集和我们的数据库架构进行创新，以使每个查询在 DuneV2 上尽可能快地运行，但是像 `tx_hash` 的查询速度很慢只是这个新数据库系统的本质。也就是说，我们认为我们在启用大量新用例和加速大量现有查询方面做得非常好。
+Some queries that were heavily indexed on our v1 database might feel a bit awkward in DuneV2. This is especially the case for erc20 event transfer tables, `ethereum.transactions` and `ethereum.logs` and their counterparts on other blockchains. This is a tradeoff we were willing to take to enable blockchain analytics on a large scale basis. We will continue to keep innovating on these datasets and our database architecture to make every query run as fast as possible on DuneV2, but things like queries for `tx_hash` being slow is just in the nature of this new database system. That said, we think we have done a pretty damn good job of enabling a lot of new usecases and speeding up a large amount of already existing queries.
-如果你对新系统有任何反馈或遇到问题，我们都会倾听并等待你在 [Canny](https://feedback.dune.xyz) 和 [Discord](https://discord.com/dunecom) 上的反馈。
+If you have any feedback or run into trouble with the new system, we are all ears and await your feedback on [Canny](https://feedback.dune.xyz) and [Discord](https://discord.com/dunecom).
diff --git a/faq/how-does-dune-get-its-data.md "b/faq/Dune\346\200\216\344\271\210\350\216\267\345\217\226\346\225\260\346\215\256\346\272\220"
similarity index 100%
rename from faq/how-does-dune-get-its-data.md
rename to "faq/Dune\346\200\216\344\271\210\350\216\267\345\217\226\346\225\260\346\215\256\346\272\220"
diff --git a/faq/does-dune-have-an-api.md "b/faq/Dune\346\234\211API\345\220\227"
similarity index 100%
rename from faq/does-dune-have-an-api.md
rename to "faq/Dune\346\234\211API\345\220\227"
diff --git a/faq/does-dune-have-a-token.md "b/faq/Dune\346\234\211\344\273\243\345\270\201\345\220\227"
similarity index 100%
rename from faq/does-dune-have-a-token.md
rename to "faq/Dune\346\234\211\344\273\243\345\270\201\345\220\227"
diff --git a/faq/how-are-results-refreshing.md "b/faq/\347\273\223\346\236\234\345\246\202\344\275\225\345\210\267\346\226\260"
similarity index 100%
rename from faq/how-are-results-refreshing.md
rename to "faq/\347\273\223\346\236\234\345\246\202\344\275\225\345\210\267\346\226\260"
diff --git a/onboarding/onboarding-to-dune.md b/onboarding/onboarding-to-dune.md
index 658fd21..95b6146 100644
--- a/onboarding/onboarding-to-dune.md
+++ b/onboarding/onboarding-to-dune.md
@@ -1,26 +1,28 @@
-# 入门Dune
+# Onboarding to Dune
+### Dune is an open platform that anyone can build on
-### Dune是任何人都可以在上边Build的开放平台
-
-Dune团队经常被问到关于”可能的合作”以及“合作方式”.我们感谢所有这些善意的请求，但是如果你想要在Dune上展示自己的数据，你确实不需要任何来自Dune核心团队的许可或者同意。 \
+Team Dune often gets asked about "possible cooperation" and "ways to work together" and while we appreciate all these kind requests, there really isn't anything you need from the core team to be able to surface your data on dune. \
\
-我们的平台是免费的、开放的以及无需许可的，任何人都按照他们认为适合的方式去使用这个平台。\
-你所需要的只是一名熟练的自由职业者或你的一个团队成员来处理实际要展示的数据。
+Our platform is free, open and permissionless and anyone can use the platform as they see fit. \
+All you need is either a skilled freelancer or one of your team members to take care of the actually surfacing the data.
-**过程如下:**
+**The Process looks like this:**
-1. **整理一份所有相关合约的清单并把他们提交**[**解码**](../duneapp/adding-new-contracts.md)**。**
-2. **使用SQL Queries查询数据**
-3. **把查询结果给可视化**
-4. **在Dashboard上把可视化的结果组装起来.**
-5. **把看板做得更美观**
-6. **享受你的数据**
+1. **Compile a List of all relevant contracts and submit them for** [**decoding**](../duneapp/adding-new-contracts.md)**.**
+2. **Surface the data using SQL queries**
+3. **Visualize the results**
+4. **Assemble visualizations on a dashboard.**
+5. **Make the dashboard pretty**
+6. **Enjoy your data**
****
-### 如何找到一个自由职业者
+### How to find a freelancer
+
+There is quite a few people in the web3 scene which either specialized in building on dune or have the skillset in their repertoire. To reach out to this pool of freelancers, you can **fill in this** [**form**](http://bounties.dune.xyz/) **** and freelancers will get back to you in little to no time. Alternatively, you could also use platforms like gitcoin or layer3.xyz to find suitable freelancers.
+
+If hiring a freelancer for the first time, please make sure to check their past works and dashboards to verify that they are indeed capable of solving the task at hand.
+
-Web3场景中有很多这样的人，他们要么专职在Dune上building，要么在他们本身有这个技能点。如果你想要联系这群自由职业者，**你可以填写这个**[**表格**](http://bounties.dune.xyz/) 自由职业者会很快回复你。或者你也可以使用 gitcoin 或 layer3.xyz 等平台来寻找合适的自由职业者。
-如果你是第一次聘请自由职业者，请务必查看他们过去的作品和仪表盘，以确认他们确实有能力解决手头的任务。
diff --git a/sharing/attribution.md b/sharing/attribution.md
index 1a3cc55..30b1852 100644
--- a/sharing/attribution.md
+++ b/sharing/attribution.md
@@ -1,19 +1,19 @@
---
-说明: Dune上的内容是社区创作的，所以也归属于社区。
+description: Content on Dune is community created and should be attributed accordingly!
---
-# 内容归属
+# Attribution
-### 内容归属
+### Attribution
-Dune上的创作内容毫无疑问地是平台创作者的成果。\
-在任何其他平台引用Dune上的分析内容，不仅要归功于Dune，还要归功于引用内容的创作者。\
+Content on Dune is first and foremost the product of the creators on the platform. \
+Any mention of analysis published on our platform outside of the platform should credit the creators of this specific piece of analysis and not just "Dune". \
\
-引用图标和仪表盘可以这样归功于创作者:
+Crediting charts and dashboards should be done in the following way:
_"@eliasmos via_ [_https://dune.com/queries/610591_](https://dune.com/queries/610591)_"._
-你可以在创作者的个人页面中找到他们的推特和更多信息[个人页面](https://dune.xyz/rchen8)。
+You can find the twitter tags and more information of most creators in their [profile page](https://dune.xyz/rchen8).
diff --git a/sharing/embeds/README.md b/sharing/embeds/README.md
index 63dc8fa..a6e75a0 100644
--- a/sharing/embeds/README.md
+++ b/sharing/embeds/README.md
@@ -1,41 +1,41 @@
---
-说明: 嵌入功能使你能跨网站地使用实时更新的Dune图表！
+description: Embeds allow you to enjoy beautiful, updating dune charts across the web!
---
-# 嵌入功能
+# Embeds
-## 使用嵌入功能
+## Using Embeds
-**截图是无趣和过时的。**
+**Screenshots are boring and tech of the past.**
-Dune自带可以跨平台使用的嵌入功能，而不是使用形式不一的截图功能。
+Instead of using static screenshots in varying forms of quality, Dune has a native embed function that works across most platforms.
-你可以在查询标题生成嵌入链接或者选择右上角的嵌入功能。
+You can generate embed links by clicking on any query title and selecting the embed function in the top right corner.
-### 参数化嵌入
+### Parameterized embeds
-参数化的查询也是可以实现的，但这需要一点技巧：
+Embed links also work with parameterized queries, but it is a bit tricky to get them to work:
-生成的嵌入链接并不包含必要的参数，尽管查询已经被执行过。我们正在致力于实现自动化的生成链接，但是目前仅有这一条途径能够做到。
+The embed link that gets generated does not include the necessary parameters yet, even if you have ran the query with it. We are already working on automating the link generation, but for now the is the only way for us to handle this.
-现在你需要在链接前手动输入参数。
+For now you need to manually prefix the parameter link with the parameters.
-输入参数的写法是这样的：
+The syntax for this is:
`link?name_of_parameter1=xxxx&?name_of_parameter2=yyyy&...` __
-一个示例：
+An example of this would be:
`>https://dune.xyz/embeds/118220/238460/aa002dd3-f9e2-4d63-86c8-b765569306c6NFT?address=0xff9c1b15b16263c61d017ee9f65c50e4ae0113d7&rolling_n_trades=500`\
``
-### 在不同平台上嵌入
+### Embeds across different platforms
-这里有几个使用Dune嵌入的示例：
+Here is a couple of exemplary use cases for Dune embeds:
{% content-ref url="discord.md" %}
[discord.md](discord.md)
@@ -55,9 +55,9 @@ Dune自带可以跨平台使用的嵌入功能，而不是使用形式不一的
-### 已知问题
+### Known Issues
-然而嵌入功能在一些比较流行的网站上还不能实现，这包括：
+Unfortunately, embeds do not work in a couple of fairly popular sites, this includes:
* substack
* medium
diff --git a/sharing/embeds/discord.md b/sharing/embeds/discord.md
index cc54744..6c4c434 100644
--- a/sharing/embeds/discord.md
+++ b/sharing/embeds/discord.md
@@ -1,14 +1,14 @@
---
-说明: Dune可以完美地嵌入Discord展示!
+description: Dune's embeds display beautifully in Discord!
---
# Discord
-Dune嵌入功能在discord上的效果非常好:
+Dune embeds work very well in Discord:
-你可以简单地在聊天框里发送链接，相应的可视化内容就会被展示。
+You can simply drop the link in the chat and the corresponding visualization will get displayed.
-这也非常适合编程一个机器人，以便在命令中返回相应的图表。
+This also lends itself very well to programming a bot to return the corresponding charts on command.
diff --git a/sharing/embeds/known-issues.md b/sharing/embeds/known-issues.md
index d5e9b5f..c9b8ade 100644
--- a/sharing/embeds/known-issues.md
+++ b/sharing/embeds/known-issues.md
@@ -1,10 +1,10 @@
---
-说明: 并不是所有网站有想要嵌入功能。
+description: Sadly not every website wants to make it.
---
-# 已知问题
+# Known Issues
-这些网站目前还不支持Dune的嵌入功能:
+These websites currently sadly do not support dune embeds:
* substack
* medium
diff --git a/sharing/embeds/mirror.xyz.md b/sharing/embeds/mirror.xyz.md
index 8ee786e..feb56a9 100644
--- a/sharing/embeds/mirror.xyz.md
+++ b/sharing/embeds/mirror.xyz.md
@@ -1,11 +1,11 @@
---
-说明: Dune嵌入功能可以在Mirror.xyz上使用!
+description: Dune embedds work in Mirror.xyz!
---
# Mirror.xyz
-Dune的图表可以很轻松地嵌入mirror.xyz的文章。生成一个嵌入链接然后加上`?display=iframe`的后缀就会实现。
+Dune charts can easily be embedded into articles on mirror.xyz. Simply generate an embed link and postfix it with `?display=iframe`
-一个示例:
+An example of this would be:
`https://dune.xyz/embeds/208941/391702/34ee3319-1cac-40e1-a08d-160bd93693cc?display=iframe`
diff --git a/sharing/embeds/twitter.md b/sharing/embeds/twitter.md
index d293102..83e670a 100644
--- a/sharing/embeds/twitter.md
+++ b/sharing/embeds/twitter.md
@@ -1,15 +1,16 @@
---
-说明: >-
- 在推特上分享是Dune的可视化内容最常见的使用场景了。
+description: >-
+ Sharing data on Twitter is probably the most common use case of Dune's
+ Visualizations.
---
-# 推特
+# Twitter
-你可以使用嵌入功能在推特上分享可视化内容。
+You can use embeds to share Dune's visualizations on Twitter.
-推特将自动呈现可视化效果，并随着时间的推移自动更新。
+Twitter will render the visualizations automatically and they will update automatically as time progresses.
-与静态的截图相比这绝对是更好的体验！
+Definitely a better experience compared to static screenshots!
diff --git a/sharing/embeds/webpages.md b/sharing/embeds/webpages.md
index 292e996..a56031e 100644
--- a/sharing/embeds/webpages.md
+++ b/sharing/embeds/webpages.md
@@ -1,20 +1,20 @@
---
-说明: 你可以在把Dune的可视化内容嵌入大多数网站上。
+description: You can embedd Dune's Visualizations on most Websites with ease.
---
-# 网页
+# Webpages
-### Dune的图表可以在你的网站上实时更新!
+### Dune Charts can live in your website!
-你可以使用Dune的嵌入功能来在你的网站上展示Dune上的内容。
+You can use Dune's embed function to embed the charts usually displayed on Dune Analytics Dashboards into your website.
-这是一段代码示例:
+Here is a code snippet example:
``
-我们已经看到这个功能在很多网站上被使用了，比如项目网站，研究者的网站等等，现在唯一的限制就是你的想象力了！
+We have seen this feature used on project websites, websites of researchers and basically everywhere by now, the limit really is just your imagination.
-这里有一个很好的展示 [cryptoart.io](https://cryptoart.io/data) 网页。
+A great showcase for this is the [cryptoart.io](https://cryptoart.io/data) website.