CosmWasm vs Secret CosmWasm

An introduction to the differences between standard CosmWasm smart contracts and Secret Contracts
Cosmwasm and Secret
Secret Contracts are an implementation of the Rust-based library CosmWasm, while additionally enabling computation with private metadata. This brings unique use cases to Secret Network which aren’t possible on other blockchains, and also means that Secret Contracts have features that are different from standard CosmWasm contracts including: contract hashes, a specialized approach to iterators, raw queries, and contract migration. 
Let's begin with an overview of these concepts before an in-depth analysis of a smart contract that can be deployed on a vanilla CosmWasm chain as well as Secret Network. 
Contract Hashes
Contract hashes are required to bind a transaction to the specific contract being called. Otherwise, in a forked chain you could replace the called contract with one that decrypts and prints the input message.
Iterator Feature
Secret contracts do not have access to standard CosmWasm iterators because keys and values of data are encrypted when stored on-chain. This means that there is no logical structure that can allow iteration over these keys. However, Secret Labs has developed iterator functionality that can be imported using the Secret Toolkit storage package.​
Raw Query
Raw queries are not available since raw data is encrypted when stored on-chain. Data can be decrypted only by the contract that owns the data, and so data is only available via permissioned contract queries (smart queries).
Migrate Function
The implementation of the CosmWasm runtime on Secret Network is designed to safeguard against unauthorized access to data stored within smart contracts. Specifically, the platform disallows the native migration of contracts, which effectively ensures that any data written to storage using a given contract can only be accessed by that same contract. This crucial aspect of Secret Network's approach to smart contract management ensures the utmost privacy and security for its users.
Crosschain Contract Demo
The crosschain contract that we are examining can be cloned from this repo. This repo is a demo of writing a simple voting contract that is intended to be deployed on multiple chains with different types of CosmWasm in a single codebase. This demo supports two types of CosmWasm: vanilla (i.e. original, like Terra or Juno supported) and secret (i.e. SecretNetwork supported).
The contract code uses conditional compilation and feature flags in Rust to support different configurations within a single codebase. If you navigate to contract.rs, you will find two sets of imports for different features, either "secret" or "vanilla". The imports are conditionally compiled using #[cfg(feature = "…")] attributes. The "secret" feature uses the secret_std crate, whereas the "vanilla" feature uses the cosmwasm_std crate.
Contract.rs
Contract.rs defines several functions:
1.instantiate: This function initializes the contract and sets the initial vote count for both options to 0. In this instance, it is the same for both Secret and vanilla CosmWasm. 
2.execute: This function processes the ExecuteMsg, which supports voting. It calls the vote_impl function to perform the vote.
3.vote_impl: This function is implemented twice, once for each feature ("secret" and "vanilla"). It checks whether the voter has already voted, and if not, it updates the tally for the chosen option.
4.query: This function processes QueryMsg, which supports two queries: getting the vote tallies (Tally) and getting a list of voters (Voters). For the Tally query, it returns the vote count for both options. For the Voters query, it calls the voters_query_impl function.
5.voters_query_impl: This function is also implemented twice for each feature. It retrieves the voters list based on the provided page number.
Let's examine the differences in vote_impl based on which type of CosmWasm we are using. The overall structure and logic of the function are the same, but there are differences in the specific methods called on the VOTERS, OPTION_1, and OPTION_2 objects. These differences arise from the different crates used for the "secret" and "vanilla" features. 
fn vote_impl: Secret
In the "secret" version of vote_impl:
1.VOTERS.contains(deps.storage, &info.sender) is used to check if the voter already exists in the storage.
2.VOTERS.insert(deps.storage, &info.sender, &1) is used to insert the voter into the storage.
#[cfg(feature = "secret")]
fn vote_impl(deps: DepsMut, info: MessageInfo, option: u64) -> StdResult<Response> {
    if VOTERS.contains(deps.storage, &info.sender) {
        return Err(StdError::generic_err("already voted"));
    }
​
    VOTERS.insert(deps.storage, &info.sender, &1 /* arbitrary value */)?;
​
    // Update tally
    match option {
        1 => OPTION_1.update(deps.storage, |tally| Ok(tally + 1))?,
        2 => OPTION_2.update(deps.storage, |tally| Ok(tally + 1))?,
        _ => return Err(StdError::generic_err("unsupported option")),
    };
​
    Ok(Response::default())
}
fn vote_impl: Vanilla CosmWasm
In the "vanilla" version of vote_impl:
1.VOTERS.has(deps.storage, info.sender.clone()) is used to check if the voter already exists in the storage.
2.VOTERS.save(deps.storage, info.sender, &1) is used to save the voter into the storage.
#[cfg(feature = "vanilla")]
fn vote_impl(deps: DepsMut, info: MessageInfo, option: u64) -> StdResult<Response> {
    if VOTERS.has(deps.storage, info.sender.clone()) {
        return Err(StdError::generic_err("already voted"));
    }
​
    VOTERS.save(deps.storage, info.sender, &1 /* arbitrary value */)?;
​
    // Update tally
    match option {
        1 => OPTION_1.update(deps.storage, |tally| Ok::<u128, StdError>(tally + 1))?,
        2 => OPTION_2.update(deps.storage, |tally| Ok::<u128, StdError>(tally + 1))?,
        _ => return Err(StdError::generic_err("unsupported option")),
    };
​
    Ok(Response::default())
}
The rest of the function, including the match statement for updating the vote tally, is the same between the two versions. Now let's examine the difference in querying functions between the two versions. 
fn voters_query_impl: Secret
Vanilla CosmWasm Iterators are not supported on Secret Network because users cannot iterate over data stored by different users as there is no access to their dedicated encryption key. However, iteration is still possible on Secret Network through the use of the secret_toolkit for storage in place of cosmwasm_std. 
In the "secret" version of voters_query_impl:
The VOTERS.paging_keys(deps.storage, page, PAGE_SIZE as u32)? method is used to retrieve a list of voters corresponding to the requested page. This method is specific to the secret_toolkit storage API and directly handles pagination. 
#[cfg(feature = "secret")]
fn voters_query_impl(deps: Deps, page: u32) -> StdResult<QueryRes> {
    let voters = VOTERS.paging_keys(deps.storage, page, PAGE_SIZE as u32)?;
    Ok(QueryRes::Voters { voters })
}
fn voters_query_impl: Vanilla
In the "vanilla" version of voters_query_impl:
The VOTERS.keys(deps.storage, None, None, cosmwasm_std::Order::Ascending) method is used to retrieve an iterator over all the keys (voters) in the storage. Pagination is implemented manually in the function.
#[cfg(feature = "vanilla")]
fn voters_query_impl(deps: Deps, page: u32) -> StdResult<QueryRes> {
    use cosmwasm_std::Addr;
​
    let voters_iter = VOTERS.keys(deps.storage, None, None, cosmwasm_std::Order::Ascending); //.paging_keys(deps.storage, page, 20)?;
    let voters: Vec<Addr> = voters_iter
        .skip((page as usize) * PAGE_SIZE)
        .take(PAGE_SIZE)
        .filter(|v| v.is_ok())
        .map(|v| v.unwrap())
        .collect();
    Ok(QueryRes::Voters { voters: voters })
}
The main difference between the two implementations is that the Secret version relies on a secret_toolkit pagination method (paging_keys), whereas the Vanilla version manually implements pagination using iterator methods.
State.rs: Secret vs CosmWasm
The contract uses state_secret or state_vanilla modules for managing the state, depending on the selected feature. The state management includes saving the vote counts for each option and managing the list of voters. Let's examine the differences between state_secret.rs and state_vanilla.rs. 
state_secret.rs
In the Secret version: 
1.The secret_std::Addr is used as the address type.
2.The secret_toolkit::storage::Item and secret_toolkit::storage::Keymap types are used for storage management.
3.The storage objects are initialized with Keymap::new and Item::new methods, passing the byte representation of the corresponding prefixes.
#![cfg(feature = "secret")]
​
use crate::state::{OPTION_1_PREFIX, VOTE_PREFIX};
use secret_std::Addr;
use secret_toolkit::storage::{Item, Keymap};
​
pub static VOTERS: Keymap<Addr, u8> = Keymap::new(VOTE_PREFIX.as_bytes());
pub static OPTION_1: Item<u128> = Item::new(OPTION_1_PREFIX.as_bytes());
pub static OPTION_2: Item<u128> = Item::new(OPTION_1_PREFIX.as_bytes());rust
state_vanilla.rs
In the Vanilla version:
1.The cosmwasm_std::Addr is used as the address type.
2.The cw_storage_plus::Item and cw_storage_plus::Map types are used for storage management.
3.The storage objects are initialized with the Map::new and Item::new methods, passing the corresponding prefixes directly.
#![cfg(feature = "vanilla")]
​
use crate::state::{OPTION_1_PREFIX, VOTE_PREFIX};
use cosmwasm_std::Addr;
use cw_storage_plus::{Item, Map};
​
pub static VOTERS: Map<Addr, u8> = Map::new(VOTE_PREFIX);
pub static OPTION_1: Item<u128> = Item::new(OPTION_1_PREFIX);
pub static OPTION_2: Item<u128> = Item::new(OPTION_1_PREFIX);
Thus, the Secret version relies on the secret_std and secret_toolkit crates, while the Vanilla version uses the cosmwasm_std and cw_storage_plus crates.  However, the overall purpose of the state management objects (VOTERS, OPTION_1, and OPTION_2) remains the same in both versions.
How to cross-deploy on different chains
//Building for Secret
make secret
​
//Building for Juno
make vanilla
​
Cross-Chain (IBC) randomness
Execution Finalization
Last modified 1mo ago