AUTO: Sync ScalarDL docs in English to docs site repo

versioned_docs/version-3.8/backup-restore.mdx

@@ -30,7 +30,7 @@ We also provide a simple client program called [scalar-admin](https://github.com
 
 Note that when you use a point-in-time-restore/recovery mechanism, it is recommended to minimize the clock drifts between nodes (ScalarDL nodes and a client node that requests a pause) by using clock synchronization such as NTP.
 Otherwise, the time you get as a paused duration might be too different from the time in which the pause was actually conducted, which could restore to a point where ongoing transactions exist.
-Also, it is recommended to pause a long enough time (e.g., 10 seconds) and use the mid-time of the paused duration since clock synchronization cannot perfectly synchronize clocks between nodes.
+Also, it is recommended to pause a long enough time (for example, 5 seconds) and use the mid-time of the paused duration since clock synchronization cannot perfectly synchronize clocks between nodes.
 
 #### Database-specific ways to create a transactionally-consistent backup
 
@@ -43,10 +43,6 @@ However, if the quorum of nodes of a cluster loses their data, we need a transac
 If you want to create a transactionally-consistent cluster-wide backup, please follow [the basic strategy](#basic-strategy-to-create-a-transactionally-consistent-backup) section, or 
 stop the Cassandra cluster and take the copies of all the nodes of the cluster, and start the cluster. 
 
-To avoid mistakes, it is recommended to use [Cassy](https://github.com/scalar-labs/cassy).
-Cassy is also integrated with [`scalar-admin`](https://github.com/scalar-labs/scalar-admin) so it can issue a pause request to the application of a Cassandra cluster.
-Please see [the doc](https://github.com/scalar-labs/cassy/blob/master/docs/getting-started.md#take-cluster-wide-consistent-backups) for more details.
-
 **Cosmos DB**
 
 You must create a Cosmos DB account with a Continuous backup policy enabled to use point-in-time restore (PITR) feature. Backups are created continuously after it is enabled.

versioned_docs/version-3.8/getting-started.mdx

@@ -119,7 +119,7 @@ Note that you can only add new certs and cannot update existing certs in place f
 
 ## Create a contract
 
-Contracts in ScalarDL are simply Java classes that extend the predefined base contract classes (such as [JacksonBasedContract](https://scalar-labs.github.io/scalardl/javadoc/latest/ledger/com/scalar/dl/ledger/contract/JacksonBasedContract.html) class) and override the `invoke` method. Let's take a closer look at the [StateUpdater.java](https://github.com/scalar-labs/scalardl-java-client-sdk/blob/master/src/main/java/com/org1/contract/StateUpdater.java) contract which creates an asset and associates some states with it.
+Contracts in ScalarDL are simply Java classes that extend the predefined base contract classes (such as [`JacksonBasedContract`](https://scalar-labs.github.io/scalardl/javadoc/latest/ledger/com/scalar/dl/ledger/contract/JacksonBasedContract.html) class) and override the `invoke` method. Let's take a closer look at the [StateUpdater.java](https://github.com/scalar-labs/scalardl-java-client-sdk/blob/master/src/main/java/com/org1/contract/StateUpdater.java) contract which creates an asset and associates some states with it.
 
 ```java
 package com.org1.contract;
@@ -237,7 +237,7 @@ First, you should always use `ClientServiceFactory` to create `ClientService` ob
 `ClientServiceFactory` caches objects required to create `ClientService` and reuses them as much as possible on the basis of given configurations, so `ClientServiceFactory` object should always be reused.
 
 `ClientService` is a thread-safe client that interacts with ScalarDL components (e.g., Ledger and Auditor) to register certificates, register contracts, execute contracts, and validate data.
-When you execute a contract, you need to specify the corresponding argument type of the contract. For example, if your contract extends JacksonBasedContract, you need to pass JsonNode argument when you execute the contract.
+When you execute a contract, you need to specify the corresponding argument type of the contract. For example, if your contract extends `JacksonBasedContract`, you need to pass JsonNode argument when you execute the contract.
 
 For more information, please take a look at [Javadoc](https://scalar-labs.github.io/scalardl/javadoc/).
 

versioned_docs/version-3.8/how-to-use-proof.mdx

@@ -22,9 +22,9 @@ Thus, making use of Asset Proofs appropriately could reduce the risk of tamperin
 
 You can get Asset Proofs ([AssetProof](https://scalar-labs.github.io/scalardl/javadoc/latest/common/com/scalar/dl/ledger/asset/AssetProof.html)) from the result ([ContractExecutionResult](https://scalar-labs.github.io/scalardl/javadoc/latest/common/com/scalar/dl/ledger/model/ContractExecutionResult.html)) of the `executeContract` method of the SDKs. A proof can be validated if it is not tampered and it is from the Ledger by verifying the signature.
 
-It is recommended to store the proofs outside of a domain in which the Ledger runs so that malicious activities in one domain can be detected by the other domain. It is worth considering storing proofs in cloud storages for ease of management.
+It is recommended to store the asset proofs outside of a domain in which the Ledger runs so that malicious activities in one domain can be detected by the other domain. It is worth considering storing asset proofs in cloud storages for ease of management.
 
-The proofs obtained in execution can be utilized when you do `validateLedger`. `validateLedger` also returns the proof of a specified asset record after doing Ledger-side validation. Then, the client can check if the proof is the same as the one that have returned from the Ledger before.
+The asset proofs obtained in execution can be utilized when you do `validateLedger`. `validateLedger` also returns the proof of a specified asset record after doing Ledger-side validation. Then, the client can check if the asset proof is the same as the one that have returned from the Ledger before.
 
 ## ScalarDL Auditor
 

versioned_docs/version-3.8/how-to-write-contract.mdx

@@ -76,7 +76,7 @@ The `StateUpdater` contract first checks if the argument has proper variables, m
 Then the contract retrieves an `asset_id` and `state` given from the requester and retrieves `asset` from the Ledger with the specified `asset_id`. And it updates the asset's state if the asset doesn't exist or the asset's state is different from the current state.
 A contract might face some `RuntimeException` when interacting with the Ledger, but it shouldn't catch it in the contract. All the exceptions are treated properly by the ScalarDL executor.
 
-This contract will just create or update the state of an specified asset, so it doesn't need to return anything to the requester. So in this case, it can return `null`. If you want to return something to a requester, you can return an arbitrary `JsonNode` when using JacksonBasedContract.
+This contract will just create or update the state of an specified asset, so it doesn't need to return anything to the requester. So in this case, it can return `null`. If you want to return something to a requester, you can return an arbitrary `JsonNode` when using `JacksonBasedContract`.
 
 ### Grouping assets
 The value of `asset_id` can be arbitrarily defined but it is a good practice to have some rules when you want to group assets.

versioned_docs/version-3.8/schema-loader.mdx

@@ -1,6 +1,6 @@
 # ScalarDL Schema Loader
 
-A Docker image that loads the database schemas of ScalarDL using [Schema Tool for Scalar DB](https://scalardb.scalar-labs.com/docs/latest/schema-loader).
+A Docker image that loads the database schemas of ScalarDL using [Schema Tool for ScalarDB](https://scalardb.scalar-labs.com/docs/latest/schema-loader).
 
 ## How to Run