jcarbonnell/preTrainingNEAR huggingface dataset:
NEAR Foundation Unlocks Web3 B2B Solutions with SK Inc. C&C Strategic Partnership
NEAR FOUNDATION
September 20, 2023
The NEAR Foundation is joining forces with SK Inc. C&C, a global leader in the IT industry, to help Web3 businesses expand in the region. 

The collaboration brings together two teams committed to helping companies find the right Web3 tools to make their business grow. NEAR Foundation and SK Inc. C&C agree to carry out joint research, share and support partners in both ecosystems and collaborate on marketing and raising awareness. 

“I am very pleased to collaborate with a leading company in South Korea’s IT industry like SK Inc.C&C. This partnership is expected to serve as a significant milestone, leading to the emergence of various use cases and the creation of a user-centric ecosystem,” says Marieke Flament, CEO of NEAR Foundation. 

The partnership with SK Inc. C&C will leverage the NEAR Foundation’s network to strengthen its technological and business growth, connecting with SK Inc. C&C’s local corporate clients to accelerate the recruitment of outstanding companies in the Korean market.

“Various attempts are being made to discover Web3 services connected with public blockchains across various industries, including public, financial, manufacturing, and distribution sectors. Starting with NEAR Protocol, we will strengthen our collaboration with already market-validated public blockchain companies and embark on expanding the Web3 service ecosystem,” says Cheol Choi, Head of the Web3 and Convergence Group at SK Inc.C&C 

SK Inc. C&C provides consulting services, enterprise resource planning (ERP) solutions, intelligent transportation systems (ITSs), geographic information systems (GISs), billing solutions as well as other systems and solutions used in telecommunications, financial, logistics, energy and chemical industries. The company is active in the United States, China, the Middle East and other markets in addition to South Korea. 

Asia in focus
South Korea has become a major hub for the NEAR Community. Since launching in November of 2022, NEAR Korea Hub has hit a number of major milestones in the Korean Web3 industry. 

The Hub has significantly contributed to the expansion of the Web3 ecosystem over the past 6 months by forming partnerships with leading domestic technology companies, offering generous developer support, and forging long-term relationships with college blockchain clubs. 

The partnership with SK Inc. C&C forms part of a wider strategy to help support Asia’s role in mainstream adoption of Web3 and Open Web technologies. The NEAR Foundation’s support of ecosystems across Asia culminated in its recent NEAR APAC conference that took place in Ho Chi Minh City, Vietnam. 
“NEAR Protocol is actively making moves to conquer the Korean market. As evidenced by the management team’s visit to Korea during Korea Blockchain Week (KBW), where discussions were held with leading companies in various industries, we expect significant results initially led by SK Inc. C&C,” says Scott Lee, General Manager, NEAR Korea.
# Applying chunk

## Inputs and outputs

Runtime.apply takes following inputs:
* trie and current state root
* *validator_accounts_update*
* *incoming_receipts*
* *transactions*

and produces following outputs:
* new state root
* *validator_proposals*
* *outgoing_receipts*
* (executed receipt) *outcomes*
* *proof*

## Processing order

* If this is first block of an epoch, dispense [epoch rewards](../Economics/Economic.md#validator-rewards-calculation) to validators (in order of *validator_accounts_update.stake_info*)
* Slash locked balance for malicious behavior (in order of *validator_accounts_update.slashing_info*)
* If [treasury account](../Economics/Economic.md#protocol-treasury) was not one of validators and this is first block of an epoch, dispense treasury account reward
* If this is first block of new version or first block with chunk of new version, apply corresponding migrations
* If this block do not have chunk for this shard, end process early
* Process [transactions](Transactions.md) (in order of *transactions*)
* Process local [receipts](Receipts.md) (in order of *transactions* that generated them)
* Process delayed [receipts](Receipts.md) (ordered first by block where they were generated, then first local receipts based on order of generating *transactions*,
then incoming receipts, ordered by *incoming_receipts* order)
* Process incoming [receipts](Receipts.md) (ordered by *incoming_receipts*)

When processing receipts we track gas used (including gas used on migrations). If we use up gas limit, we finish processing the last receipt and stop to process delayed receipts, and for local
and incoming receipts we add them to delayed receipts.

* If any of the delayed receipts were processed or any new receipts were delayed, update indices of first and last unprocessed receipts in state
* Remove duplicate validator proposals (for each account we only keep last one in receipts processing order)

Please note that local receipts are receipts generated by transaction where receiver is the same as signer of the transaction

## Delayed receipts

In each block we have maximal amount of Gas we can use to process receipts and migrations, currently 1000 TGas. If any incoming or local receipts are not processed due to lack of remaining Gas, they are stored in state with key <pre>TrieKey::DelayedReceipt { id }</pre> where id is unique index for each shard, assigned consecutively. Currently sender does not need to stake any tokens to store delayed receipts. State also contains special key <pre>TrieKey::DelayedReceiptIndices</pre> where first and last ids of delayed receipts not yet processed are stored.
```js
const AMM_CONTRACT_ADDRESS = "v2.ref-finance.near";
const wallet = new Wallet({ createAccessKeyFor: AMM_CONTRACT_ADDRESS });
 
await wallet.viewMethod({
  method: 'get_deposits',
  args: {
   account_id: "bob.near"
  },
  contractId: AMM_CONTRACT_ADDRESS,
});
```
_The `Wallet` object comes from our [quickstart template](https://github.com/near-examples/hello-near-examples/blob/main/frontend/near-wallet.js)_ 

<details>
<summary>Example response</summary>
<p>

```json
{
  "token.v2.ref-finance.near": "0",
  "wrap.near": "0"
}
```

</p>

</details>
---
id: introduction
title: About Rust SDK
---

Rust is a programming language designed for performance and safety. It is syntactically similar to C++, but can guarantee memory safety without resorting to garbage collection. Rust has proven to be a mature and secure language, which makes it ideal to write smart contracts. Because of this, **Rust is the preferred programming language for writing smart contracts on NEAR**. While there might be a learning curve for those coming from web development, learning Rust enables to write safer and faster contracts. Furthermore, core contracts such as Fungible Tokens and DAOs are currently only available in Rust.

:::info 
If you're getting started with Rust, we recommend you look through [this overview in the `nearcore` repository](https://github.com/near/nearcore/blob/master/docs/practices/rust.md). It's a great way to get your first steps in for the language and its ecosystem. 
:::

---

## Create Your First Rust Contract
Create your first **Rust contract** in minutes:
1. Download and install [Rust](https://doc.rust-lang.org/book/ch01-01-installation.html).
2. Create a new **rust** project using our [quickstart guide](../../2.build/2.smart-contracts/quickstart.md).
3. Read our docs on **[how to write smart contracts](../../2.build/2.smart-contracts/anatomy/anatomy.md)**.
---
id: overview
sidebar_position: 1
sidebar_label: "Crossword Game Overview"
title: "Basics overview laying out what will be accomplished in this first section."
---

import basicCrossword from '/docs/assets/crosswords/basics-crossword.jpg';
import rustScary from '/docs/assets/crosswords/rust-scary--ksart.near.png';
import rustGood from '/docs/assets/crosswords/rust-good--ksart.near.png';

# Basics overview

This first chapter of the crossword puzzle tutorial will introduce fundamental concepts to smart contract development in a beginner-friendly way. By the end of this chapter you'll have a proof-of-concept contract that can be interacted with via [NEAR CLI](https://docs.near.org/tools/near-cli) and a simple frontend that uses the [`near-api-js` library](https://www.npmjs.com/package/near-api-js).

## It's not as bad as you think

Rust is a serious systems programming language. There are pointers, lifetimes, macros, and other things that may look foreign. Don't worry if this is how you feel:

<figure>
    <img src={rustScary} alt="Programmer looking at Rust code and looking worried. Art created by ksart.near" width="600"/>
    <figcaption>Art by <a href="https://twitter.com/ksartworks" target="_blank">ksart.near</a></figcaption>
</figure>
<br/>

The good news is the Rust SDK takes care of a lot of the heavy lifting.

We'll also have the compiler on our side, often telling us exactly what went wrong and offering suggestions. As we go through this tutorial, you'll begin to see patterns that we'll use over and over again.

So don't worry, writing smart contracts in Rust on NEAR doesn't require a heavy engineering background.

<img src={rustGood} alt="Programmer looking quite relieved at the Rust code from the NEAR SDK. Art created by ksart.near" width="600"/>

## Assumptions for this first chapter

- There will be only one crossword puzzle with one solution.
- The user solving the crossword puzzle will not be able to know the solution.
- Only the author of the crossword puzzle smart contract can set the solution.

## Completed project

Here's the final code for this chapter:

https://github.com/near-examples/crossword-tutorial-chapter-1

## How it works

<img src={basicCrossword} alt="Basic crossword puzzle" width="600" />

We'll have a rule about how to get the words in the proper order. We collect words in ascending order by number, and if there's and across and a down for a number, the across goes first.

So in the image above, the solution will be **near nomicon ref finance**. 

Let's begin!
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

<Tabs groupId="nft-contract-tabs" className="file-tabs">
<TabItem value="Paras" label="Paras" default>

```js
const tokenData = Near.call(
  "x.paras.near",
  "nft_buy",
  {
    token_series_id: "299102",
    receiver_id: "bob.near",
  },
  undefined,
  205740000000000000000000 // NFT price + storage cost
);
```

**Example response:**

```json
"299102:1"
```


</TabItem>

<TabItem value="Mintbase" label="Mintbase">

```js
const tokenData = Near.call(
  "simple.market.mintbase1.near",
  "buy",
  {
    nft_contract_id: "rubennnnnnnn.mintbase1.near",
    token_id: "38",
    referrer_id: null,
  },
  undefined,
  1000000000000000000000 // NFT price + storage cost (optional, depends on a contract)
);
```

**Example response:**

```json
{
  "payout": {
    "rub3n.near": "889200000000000000000",
    "rubenm4rcus.near": "85800000000000000000"
  }
}
```


</TabItem>

</Tabs>
```js
const tokenContract = "token.v2.ref-finance.near";
const result = Near.call(
  tokenContract,
  "ft_transfer_call",
  {
    receiver_id: "v2.ref-finance.near",
    amount: "100000000000000000",
    msg: "",
  },
  300000000000000,
  1
);
```

<details>
<summary>Example response</summary>
<p>

```json
'100000000000000000'
```

</p>

</details>
# StateRecord

_type: Enum_

Enum that describes one of the records in the state storage.

## Account

_type: Unnamed struct_

Record that contains account information for a given account ID.

### account_id

_type: `AccountId`_

The account ID of the account.

### account

_type: [Account](../DataStructures/Account.md)_

The account structure. Serialized to JSON. U128 types are serialized to strings.


## Data

_type: Unnamed struct_

Record that contains key-value data record for a contract at the given account ID.

### account_id

_type: `AccountId`_

The account ID of the contract that contains this data record.

### data_key

_type: `Vec<u8>`_

Data Key serialized in Base64 format.

_NOTE: Key doesn't contain the data separator._

### value

_type: `Vec<u8>`_

Value serialized in Base64 format.


## Contract

_type: Unnamed struct_

Record that contains a contract code for a given account ID.

### account_id

_type: `AccountId`_

The account ID of that has the contract.

### code

_type: `Vec<u8>`_

WASM Binary contract code serialized in Base64 format.


## AccessKey

_type: Unnamed struct_

Record that contains an access key for a given account ID.

### account_id

_type: `AccountId`_

The account ID of the access key owner.

### public_key

_type: [PublicKey]_

The public key for the access key in JSON-friendly string format. E.g. `ed25519:5JFfXMziKaotyFM1t4hfzuwh8GZMYCiKHfqw1gTEWMYT`

### access_key

_type: [AccessKey](../DataStructures/AccessKey.md)_

The access key serialized in JSON format.


## PostponedReceipt

_type: `Box<`[Receipt](../RuntimeSpec/Receipts.md)`>`_

Record that contains a receipt that was postponed on a shard (e.g. it's waiting for incoming data).
The receipt is in JSON-friendly format. The receipt can only be an `ActionReceipt`.

NOTE: Box is used to decrease fixed size of the entire enum.


## ReceivedData

_type: Unnamed struct_

Record that contains information about received data for some action receipt, that is not yet received or processed for a given account ID.
The data is received using `DataReceipt` before. See [Receipts](../RuntimeSpec/Receipts.md) for details.

### account_id

_type: `AccountId`_

The account ID of the receiver of the data.

### data_id

_type: [CryptoHash]_

Data ID of the data in base58 format.

### data

_type: `Option<Vec<u8>>`_

Optional data encoded as base64 format or null in JSON.


## DelayedReceipt

_type: `Box<`[Receipt](../RuntimeSpec/Receipts.md)`>`_

Record that contains a receipt that was delayed on a shard. It means the shard was overwhelmed with receipts and it processes receipts from backlog.
The receipt is in JSON-friendly format.  See [Delayed Receipts](../RuntimeSpec/Components/RuntimeCrate.md#delayed-receipts) for details.

NOTE: Box is used to decrease fixed size of the entire enum.
# Access Keys

Access key provides an access for a particular account. Each access key belongs to some account and
is identified by a unique (within the account) public key. Access keys are stored as `account_id,public_key` in a trie state. Account can have from [zero](#account-without-access-keys) to multiple access keys.

```rust
pub struct AccessKey {
    /// The nonce for this access key.
    /// NOTE: In some cases the access key needs to be recreated. If the new access key reuses the
    /// same public key, the nonce of the new access key should be equal to the nonce of the old
    /// access key. It's required to avoid replaying old transactions again.
    pub nonce: Nonce,
    /// Defines permissions for this access key.
    pub permission: AccessKeyPermission,
}
```

There are 2 types of `AccessKeyPermission` in NEAR currently: `FullAccess` and `FunctionCall`. `FullAccess` grants permissions to issue any action on the account. This includes [DeployContract](../RuntimeSpec/Actions.md#DeployContractAction), [Transfer](../RuntimeSpec/Actions.md#TransferAction) tokens, call functions [FunctionCall](../RuntimeSpec/Actions.md#FunctionCallAction), [Stake](../RuntimeSpec/Actions.md#StakeAction) and even permission to delete the account [DeleteAccountAction](../RuntimeSpec/Actions.md#DeleteAccountAction). `FunctionCall` on the other hand, **only** grants permission to call any or a specific set of methods on one given contract. It has an allowance of $NEAR that can be spent on **GAS and transaction fees only**. Function call access keys **cannot** be used to transfer $NEAR.

```rust
pub enum AccessKeyPermission {
    FunctionCall(FunctionCallPermission),
    FullAccess,
}
```

## AccessKeyPermission::FunctionCall

Grants limited permission to make [FunctionCall](../RuntimeSpec/Actions.md#FunctionCall) to a specified `receiver_id` and methods of a particular contract with a limit of allowed balance to spend.

```rust
pub struct FunctionCallPermission {
    /// Allowance is a balance limit to use by this access key to pay for function call gas and
    /// transaction fees. When this access key is used, both account balance and the allowance is
    /// decreased by the same value.
    /// `None` means unlimited allowance.
    /// NOTE: To change or increase the allowance, the old access key needs to be deleted and a new
    /// access key should be created.
    pub allowance: Option<Balance>,

    /// The access key only allows transactions with the given receiver's account id.
    pub receiver_id: AccountId,

    /// A list of method names that can be used. The access key only allows transactions with the
    /// function call of one of the given method names.
    /// Empty list means any method name can be used.
    pub method_names: Vec<String>,
}
```

## Account without access keys

If account has no access keys attached it means that it has no owner who can run transactions from its behalf. However, if such accounts has code it can be invoked by other accounts and contracts.
NEARCON IRL Hackathon 2023: Build the Open Web
NEAR FOUNDATION
September 28, 2023
If you attended NEARCON last year, you know the 48-hour IRL hackathon — “Building Beyond the Hype” was a great event, with all sorts of exciting prototypes that helped propel NEAR through the last year.

For NEARCON 2023, which will be held November 7-10th, we’re leveling up the hackathon. This year’s hackathon explores NEARCON 2023’s theme — “Step into the Open Web”. And that hacking together apps and experiences that explore how the NEAR Protocol and Blockchain Operating System are paving the way for a truly open web.

Let’s explore what’s new for the NEARCON 2023 Hackathon. 


Hacker HQ: a space just for the hackers
Not only do hackers get into NEARCON 2023 for free, but they also get their own space. NEARCON’s Hacker HQ will be a place for hackers to hang out, network, and build — whether that’s for the Hackathon or if you’re just interested in continuing to build your project on NEAR. Hacker HQ will be located at: 

Armazem 16
R. Pereira Henriques nº1, 1950-242
Lisboa, Portugal

Hack the days and nights away for a chance to build on the BOS and win $140k+.

Important NEARCON Hackathon dates and information
The Hackathon is held November 7-10th.
November 7th — Hackathon orientation, team matching, and a welcome party hosted by NEARWEEK. 
November 8th — Day 1 of hacking. Mentoring available. 
November 9th — Day 2 of hacking. Mentoring available. Submission Deadline. 
November 10th — Pitch competition. 
Request a visa letter to support hackers’ visa applications. All requests must be submitted via the form by October 7, 2023. 
Travel stipends are available depending on your location. Please read the Hacker Stipend Guidelines. 
Stay tuned in the coming weeks for details on NEARCON IRL Hackathon bounties.
NEAR Developer Research: Validating the NEAR DevX Tech Stack – Round 2
DEVELOPERS
October 29, 2020
Update: We’ve quickly filled up the available sessions for this round of research, and will not be taking on any more participants. The post will remain on the blog for those interested in getting a peek at what we’re up to. For those interested in participating, check back for round 3!

After a successful first round of research diving into the developer experiences of AssemblyScript and Rust earlier this month, we’re back in action with ROUND 2. This is a compensated opportunity to contribute to the future success of NEAR and help shape the future of developer experience for the community.

Validating the NEAR DevX Tech Stack
The next big decision we welcome the community to participate in is how we will support AssemblyScript in addition to Rust as a WASM source. We want to test our assumptions about the value propositions of these languages with community developers in order to make an informed, evidence based decision on what we choose to support, and to what extent.

Round 1 of this initiative focused on reading and discussing a set of pre-written contracts.

For Round 2, we want to walk through setting up and deploying a simple contract with our developer participants in order to compare and contrast the experience between languages. If selected, participants who complete a session with us will be compensated with $50 of value in the form of a gift card or tokens depending on location.

If interested in participating, fill out this invite form to connect with our team. You do not have to have participated in Round 1 to participate in Round 2.

What you’ll do
It’s easy to join and we’re open to feedback from community members from around the world. After a quick survey and remote interview we’ll ask you to complete a few simple dev tasks and provide your feedback to the team.

Pre-interview Survey
New participants will be asked to complete a short pre-interview survey about their development experience to help us categorize feedback. 
Remote Interview (15 min)
At the start of the session, new participants will be interviewed about their development experience and their opinions about the tools that we’re testing. 
Remote Technical Exercises (35 – 60min)
Each participant will be asked to complete a series of short tasks focused on customizing a smart contract on NEAR, and to share their thoughts along the way.

Participants will be asked to:
Use create-near-app to generate new projects in Rust and AssemblyScript
Edit contract code to pass a set of pre-written unit tests
Build and deploy the contract to the NEAR Testnet
Verify that the contract works as expected and troubleshoot any issues
You’re a great fit if you fall into any of the following categories:
… you’re a developer with experience in Javascript / Typescript

… you’re a developer with experience in AssemblyScript

… you’re a developer with experience in Rust

… you’re a developer with experience in Solidity

… you’re interested in getting some hands-on time with some of the basic NEAR developer tooling.
NEAR Wallet’s Evolution in 2023
NEAR FOUNDATION
January 11, 2023
NEAR Foundation and Pagoda, along with the Wallets Working Group, have conducted extensive community discussions over the last several months about the evolution of wallets in the NEAR ecosystem. In keeping with the Foundation’s goal to empower the community and continue to decentralize the ecosystem over time, the focus since NEARCON has been to expand the wallet offerings to NEAR users and to decentralize the NEAR Wallet.   

MyNearWallet is now open source and under the stewardship of Developer DAO to maintain as a public good. (Pagoda took over MNW after Kikimora ceased operations in December due to funding issues.) DevDAO announced this week that they are accepting applications for teams to take over maintenance of MyNearWallet to evolve the product while keeping it open source for the benefit of the developer community. For more information about how to apply, visit the Developer DAO gigs board on NEAR Social. 

If you have been using MyNearWallet or wallet.nearpages.wpengine.com, you don’t need to take any action. MyNearWallet service will not be interrupted in this transition and, in fact, users can expect product improvements over time from the chosen maintainer team. The goal is to offer more wallet options to users across the NEAR ecosystem and to decentralize the development of wallet products across the developer community. 

Pagoda will continue maintaining wallet.nearpages.wpengine.com. Over time, the NEAR wallet will integrate into the forthcoming NEAR Discovery product. But for now, no action is needed from users. Legacy wallet users may consider migrating to another wallet now that an expanded range of options is available via Wallet Selector, which will soon live on wallet.nearpages.wpengine.com. Numerous wallets optimizing for a variety of user types, security requirements, and use cases are already available, with more on the way in Q1. 

NEAR’s commitment to serving as the de facto entry point to Web3 remains intact. Building without limits is about continuously improving on industry standards and delivering the best possible experiences to developers and users alike.