This brief tutorial will go over the steps on creating your very own Kusama Validator that can be used to either:

  1. Become your own Validator.
    If you have enough KSM to self-stake or plan to advertise your node to get others to nominate your Validator Node.
  2. Run your own Kusama Archive, Full, or Pruned node.
    Remove the --validator argument from the service description below. Skip steps that deal with accounts and session keys.

For our tech advance readers (DevOps peeps) here’s a repo that will interest you: https://github.com/w3f/polkadot-secure-validator


🙏 Thank you to everyone that participated!
🛑 The bounty has concluded and is now closed.
💲 Rewards will be sent before the end of the week!

ShiftNrg would like to invite you to our first bounty!

Participation is easy; follow these three simple steps:

  1. Join our Telegram Channel: ShiftNrg Announcements
  2. Join our Discord Community and post the following in the #bounty channel:
    A) a link to your retweet
    B) your Ethereum wallet address (to receive your wSHIFT bounty)

That’s all — you’re in!

Limited to the first 200 participants. One entry per person. One bounty per entry.

Stay tuned for more exciting updates!

Sincerely,

The ShiftNrg Team

About wSHIFT:

Wrapped Shift (wSHIFT) is our ERC20 token: Etherscan Contract.

Read about our coin/token redenomination here.


v1.5 build, had to make some customizations to the lego buildout


Awhile ago I was a node operator on Storj’s previous decentralized storage network that was meant to compete with the likes of Amazon’s storage services…


I will “quickly” show and tell how to get a full, fast sync, Ethereum mainnet node up and running via an Ubuntu VM.

Previous tutorial on getting your testnet node up and running: Geth Node via Ubuntu

During the drafting of this article, my node finished syncing! 🎆

🔢My results

  • 30 hours and 40 minutes from start to finish (this includes ~20 minutes of total downtime from me goofing around with the Ubuntu max open file limit)
  • Increased my peer count to 100 from 50 & soft limit of files open from 1024 to 4000

📝 First, some quick stats, for the record, regarding node disk size requirements. As I’ve seen some false truths regarding node size requirements from elitists/maximalists.


Requirements:

  • Existing knowledge of Solidity, Truffle, and NPM tooling

Example Solidity Code:

contract Overloading {
function init(uint256 _id) public {}
function init(uint256 _id, address _signer) public {}
}

Please note the code above is not complete. Nor is the test case below.

Testing via JS:

context('called by invalid signers', () => {
it('should fail', async () => {
await expectThrow(contractInstance.init(4, {from: nonSigner}));
});
});

The above test case will fail!

⚠With this error:


The following is a quick & dirty way to get a node up and running. This example will list instructions for a testnet node. This running instance will run as an Ubuntu service! Meaning if you’re server restarts for whatever reason geth will restart with it! 😎

Disclaimer: I am a happy Digital Ocean customer, but was not paid to advertise for them. 😜

Things needed in this guide:

Ubuntu Server via Digital Ocean (Referral Link: https://m.do.co/c/2e7929d058d5)

PuTTY

Keyboard & Internet Connection

Geth Command Line Options

Server: I’d recommend starting off with their flexible 2GB, 2 vCPU, 60 GB $15 droplet. That’s a sweet spot.

You got your server, you connected via PuTTY. Great!
(Hopefully you’re using ssh keys and not passwords… You’re not…


One might wonder, how is it possible to essentially throw a UI on top of a Smart Contract and make it intuitive without sacrificing functionality?

Answer: You start small. You build with the minimal amount needed to complete a use case. Once that initial stepping stone is complete, you iterate, test, and deploy until it’s near-perfect and scalable. From there you add more functionality, account for edge case, iterate again, and again, several more times all while polishing the UI. …


Smart Contracts fronted by a great UX & UI to enable the power of CSCs. (Configurable Smart Contracts)

Pactum: [Latin, Pact.] A compact, bargain, or agreement.

Pactum is a DApp that will allow users to choose from a “library” of Smart Contract Templates that fits their general use case. Furthermore, a user can customize the variables and conditions to fit their use case exactly as they see fit. This entails filling out an easy to use web form to customize said Smart Contract, along with automated verification and deployment to the EVM on their behalf.

  • Enabling P2P Pacts World Wide.
  • Encouraging mass adoption of Ethereum.

Pactum is Solving the Following Problem

Ethereum’s Smart Contracts are not trivial to develop and design. The average user does not have the…


Smart Contracts == Digital Agreements

Smart Contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.

Background & History

The first smart contract concept was actually introduced well before any blockchain technology was even in existence. Crazy right!? Smart contracts were first proposed by Nick Szabo in 1994. Szabo is a computer scientist, legal scholar, and cryptographer who is a well respected academic with research in digital contracts and digital currency. Many people in the cryptocurrency community even assert that he anonymously created Bitcoin. Szabo denies this claim.

Nick Szabo, in 1996, described a smart contract as “ a set of promises, specified in digital form, including protocols within which the parties perform on these promises…”

It’s only appropriate…

Matt Swezey

Software Engineer & Founder @ Pactum IO

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store