I'll see you in the next video.
Alright, so hello everyone, I apologize for a little bit, you know, like, it's always
Everything works and then at the last minute something happens, so I would like to welcome
our two VAR core developers, Vadim and Dima, hello guys, how are you?
Oh, great, nice to see you again.
Alright, so it looks like our devs are super excited about this session today with you,
and I'm excited as well, so just like to start with some introduction, we do this AMA session
with VAR core devs on a regular basis, usually it's each month or each second month.
We always share like a survey or form for you to fill out your questions, and then those
questions are answered during this AMA.
We actually last month we tried to have an AMA on LinkedIn, because it's sad that it's
going to be recorded, and then, you know, it records only for LinkedIn, you use it,
so we couldn't really like share it to public, so I apologize for that, but here we are again
on Twitter, and I think I will not prolonging more, and we can just jump to the first question.
So guys, are you ready for to start?
Okay, so let's start with the first question, which is, how do you stay up to date with
the latest developments and best practices in your field?
Do you even stay up to news?
So it's a more general question, and maybe Vadim, can you take this one please?
Yeah, I'll answer this, it's a great question.
So actually, we make sure to keep ourselves informed about new technologies and trends
One way we do this by exploring different implementations in other blockchain projects,
we look at how other blockchains are solving similar problems, and see if we can learn
anything from their approaches.
This helps us to identify new ideas and strategies that we can apply to our own work.
In addition, we're also implementing our own solutions, so this allows us to stay creative
and innovative in our space, and it's a great opportunity for us to stay up to date and
So sometimes we join some conferences and learn new stuff from there, so yeah, that's
All right, and do you, for example, read some newsletter, or do you watch some YouTube video
guy talking about desktop?
Do you also do something like that in your free time?
Usually, I read new articles about technology stuff in blockchain space, and exploring
in my free time new approaches, solutions.
Let's move to the second question, and let's go with you, Dima, and the question sounds.
How to design DAP architecture that can scale in the future with ease, especially when off-chain
sub-systems are involved, such as oracles, price feeds, data indexing services, and et
Yeah, I hope you can hear me well.
Yeah, speaking of designs of DAP architectures and scaling solutions, it's kind of interesting
I don't actually think it's possible to give some specific advices that would be applicable
to all programs, but however, I guess it's possible to highlight some general scaling
conditions, and first of all, I think when developing some protocol, it's necessary
to consider how you're going to interact with your data, how you're going to store it.
For example, if you anticipate having a large amount of some temporary data, unless probably
permanent or not permanent, but some data that intends to be stored for a long time,
you might want to consider creating some special different separated actor that you'll implement
a storage solution, while temporary data will be stored besides some of your mechanism
of processing your requests.
This kind of approach will also allow you to implement some upgradability of your DAP.
For example, if you want to change your processor, but you don't want to migrate storage, or
you don't want to change the structure of the data you keep, you can go with something
It will also allow you to build some system of changed actors that interact with each
For such models, I guess it's nice to have some kind of governance or DAO mechanism,
just because simple admin accesses are not that much good in the modern realities, because
we all want to be decentralized, as decentralized as it could be.
So returning to the original question, I think the second recommendation will be something
to go around parallelism on the bar network, just because we have such architecture.
This approach will enhance your throughput, for instance, if a significant portion of
the computations is kind of independent from the data store, it's time, like it's a good
time to create multiple instances of the same program with the same code, doesn't matter.
And for example, teach your front-end or back-end site to monitor the state of this program,
the state of the chain, and proxy traffic from your end users to these applications.
So in the same time, the bar network will ensure this request to be executed in the
different threads, but still included in the same block.
Also, it's worth noting that you can take any approach you like on the bar network,
because you cannot invent any arbitrary logic for your business.
And many time-tested patterns also deserve attention, I guess.
For example, a combination of two scaling approaches mentioned already, they're strongly
similar to the classic design of model or web 2.0 back-end, I guess.
And the last part was about chain systems, am I right?
If you consider some of chain systems or external data providers, I prefer to spread
them into individual actors as well, into separate program on chain.
Because this will allow other network participants out of the apps or even end users to interact
with your program, with your external data provider, and also divides the data traffic
into some several stages.
For example, the first stage will be collection and submitting data to the network.
It will be done off-chain.
Then go to data validation in your dedicated actor, just because every time you use something
off-chain, you need to validate the data that it's normal.
Probably you could check the science of your Oracle or whatever else.
It will be the second stage.
And the third step or stage, it will be the processing in the primary application, where
you already got valid data from off-chain, and you need to do something with this.
In any particular case, we may discuss, if you would have some from our listeners, if
you would have some idea of the apps, we can discuss its design maybe on the next AMA,
So we actually even have Oracle's article out about the use cases, also like uses in
So definitely check that out.
I might add the link here, because I was reading and it's very well explained.
So even if you are not a deaf person, you will at least understand the main points,
which I think is the most important.
And let's move to our another question, which is, what is the most proper way, such as standard
template for communication between front-end and smart contract, smart contract and smart
contract, especially when guest reservation, automated self-messaging, and et cetera?
So Dima, do you want to talk more?
Yeah, it's kind of linked to the previous question, which is because I was speaking
about these interactions.
But anyway, we can start from the beginning.
The communication process is quite standard, like for almost all of the existing blockchains,
just because you have some clients or RPC nodes and something, you have a front-end
and you need to somehow make them communicating.
So to connect the front-end to your program, especially to the chain, you will be required
to have some library that will allow you signing and sending transactions to the network.
For example, within our actor model, messages are, let's say, utilized.
There is a specific call that front-end will need to make from our runtime.
The payload of the message, it's like the data we want to send to the program, to share,
to execute, whatever, is already defined by each protocol, by each program, in its
It's like common standard, where when you send only sequence, let's say like tech terms,
you send only a vector of bytes.
And the program already knows how to interpret all this.
So the same process applies to interactions between programs, with only one exception
that you don't need anything external to send messages or sign them, just because inside
the programs on a good protocol, you already have some predefined syscalls by your environment,
by your executable environment.
So you can only just code, like, call these functions and message, and at the end of the
processing of your program, of your message, the new message will be created and stored
inside the database, the blockchain, and the other authors will be able to protest
them and say for like next blocks.
So speaking of those reservations and automatic, some stuff, so self messaging and so on.
It's not like, do not serve as the means of communication.
It's instead, they provide some kind of autonomy for programs within the protocol.
It doesn't about the communication at all.
It's about their own lifecycle.
And let's move to our another question.
And Vadim, since you've been quiet for some time, I'm gonna give this to you.
How does the use of substrate contribute to the stability and upgradeability of VAR
And what advantages does this provide for the network's long term development and evolution?
So we dive a little bit with this question to substrate and connection to VAR.
So substrate is a model, modular blockchain framework that provides a foundation for building
custom blockchain networks.
VAR network is built using substrate, which enables it to leverage several technical advantages
that contribute to stability and upgradeability.
So firstly, substrate's modular architecture enables VAR network to easily add, remove
or modify features and functionality without affecting the underlying code base.
So this is achieved through the use of substrate frame palettes, like default palettes, balances,
like system palettes and underlying code base, which are built for built modules that can
easily be integrated into the network.
This modularity allows VAR to quickly adapt to changing requirements and to implement
new features without compromising the stability of the network.
So for example, Polkadot built using substrate, Kusama and other like standalone networks.
And they share the same code base and it's stable.
So secondly, substrate forkless upgrade mechanism enables VAR network to seamlessly upgrade
its runtime without requiring a hard fork.
This is achieved through the use of VAR network's on-chain governance system, which allows
stakeholders to vote on and approve proposed upgrades.
Once approved, the new runtime is deployed on-chain and the next network automatically
switches to the new version without any downtime or disruption.
This ensures that VAR network remains up-to-date with the latest security patches and features
while minimizing the risk of network disruptions or forks.
So yeah, substrate is like a great foundation for our network.
All right, so when we are talking about like, you know, stable network, then this question
I think it's a little bit follow-up and it sounds, how do you approach testing and quality
assurance in your projects?
And is there something like an open QA guild program?
Can people test out the stuff before going live?
So Dima, could you take this one, please?
Yeah, finally, here's a question about developing and testing.
It's pretty interesting always.
Yeah, guys, today's are like only two of us is here, but I swear other guys is doing something
great right now for the future of a tree and the VAR network as well.
So speaking of security, testing and stability, developing team vertical always pays great
attention to the testing of the code we write or which was already written before.
We kind of would say emphasize that each programmer is both as a tester and the programmer at
So everyone is responsible for covering their own code with a variety of tests and something,
including the QA, some stuff.
A lot of attention is given on the code reviews and on the quality of these reviews.
So you can check out our GitHub, it's like open source so we all know and you can monitor
how we interact with each other, how we review, how we re-review and like doing some new stuff.
So speaking of additional measures, we have been developing, improving and running some
fuzzer, 25, 24 and five as well per seven days.
So every day for a long time we are running this fuzzer.
The fuzzer is some automatic random generator of the inputs for our runtime, which is included
in our not client, but not in the public, but in the private one.
Private, I mean, not like close source, I mean, we don't use it exactly on chain, we
run it off chain every time to check any bugs detected in the runtime.
So if rare occurrences happen, they are fixed instantly always, so we work, we hardly work
Additionally, they have been running and still running the bug bounty program on E-Munify,
It was for a long time, so anyone can still participate in finding bugs and issues in
the protocol, maybe in front ends, but it's kind of out of scope.
Probably E-Munify, it's mostly about the runtime, but any QA issues from the back ends, front
ends could be written in our Discord, and we will always reflect and answer you and
help with everything you want.
Yes, so like we have a support channel in Discord, we also have a help channel in Telegram.
So like, also, if you find something, for example, last week we had a guy who felt like the
website is super slow and blah, blah, blah, and then we just check it and it was actually
So like, you know, there are always some troubles or issues which might seem as an issue, but
are pretty easily solved.
So don't be afraid to ask any question because no question is stupid or how I like to say,
like, I always ask so many questions.
So I really know what's going on.
And yeah, let's move to the next question, which is actually about the future.
So what is next for VORA?
Is it possible to make the network even better?
That sounds really great.
What are you working on now?
So guys, can you make the network even better?
Yeah, it's a great question.
But like, guys, just do better.
Do well and everything will be good.
Yeah, but anyway, as you all know, there is no limit to perfection and nothing is perfect
in the universe, I guess.
However, more importantly, when any project comes to release, making their project live,
how it was for VORA, for example, it begins to take a new direction and so on.
It's only start always, only beginning.
So within the VORA network, I guess there is like a huge space for plenty of ideas to
be implemented to use something new that have been developed by the tech community across
the world, like some cutting edge technologies and approaches.
Additionally, it's essential to enhance some stability and like, let's say, full tolerance
stuff on the like regular basis.
Sorry, I just got some issue on the Twitter, just changing the theme.
So what I was about, yeah, some new approaches.
We are focusing on fixes of the bugs, increasing the speed of processing programs, decreasing
gas prices, decreasing prices for the gas, increasing throughput and how everyone likes
to ask transactions per second, TPS, we are also working on it, we are working on stability
There is a lot of things to be done in future, especially speaking of user space libraries,
just because we claim that everyone can come to the VORA network and make your own
development like in five minutes and something like this.
So speaking of what are we like working on now, for example, for example, it's the concept
of built-in actors, which is currently being actively developed and the framework for them
to be implemented on-chain is already in our master branch and a GitHub and will be included
in the next release and it will be like in one day, maybe, one, one, two.
And this framework will allow the implementation, for example, of staking for programs and many
other interesting things as BLS, BLS chip calculations from the programs.
So I guess, as always, guys, stay tuned.
There is much, much interesting things coming in the future.
Follow the official announcements and you will not miss any news or updates.
And let's move to our next question, which is, what is Gear.js and what's the need for it?
What's the either way of utilizing it for development?
So, Vadim, what do you think about it?
Gear.js is a great tool to develop your own app or front-end or back-end APIs for the bottom
So this is basically a set of utilities, libraries and tools to send messages to a program, read
the program's date and query and interact with all Gear-specific data, such as messages,
programs, users and balances and taking any on-chain like interactions.
Also provides meters for calculating gas for messages, getting transaction fees and even
presuming positive programs or upload your own programs, your own code and read everything.
When it comes to creation, Gear.js can be used for front-end and back-end development.
As I said earlier, on the front-end developers can use Gear.js to create user interfaces that
interact with the blockchain network and display data to users.
This includes creating forms to submit transactions, displaying account balances and showing
transaction history and maybe some other metrics and data.
On the back-end side, Gear.js can be used to create APIs that interact with the blockchain
network, provide data to the front-end.
This includes submitting transactions and messages to program, query and program's date.
And Gear.js also provides to you the code and code payload to a program, the code program's
data and it's like a heavy tool to make your life easier.
It is a VAR network or Gear-specific protocol and data is just the main tool to build your
own front-end and back-end or service or API that can interact with the VAR network.
And it has awesome transcription, docs that you can always ask us in Discord.
Yeah, I think I covered the main features.
Basically, it's a fork of Polka.js so you can create accounts, you're interacting with them,
like any substrate base included.
As you heard, it's a heavy tool, so I posted a link for Gear Wiki where you can find all the
information that you mentioned under these spaces if it sounds interesting for you and you can
And let's move to the next question, which is how has the technical update last month
V1.1 improved and enhanced the user experience?
So for those who are not aware, this is like a regular monthly article we publish each month
And this one is referring to the last one, which you can find on Gear Twitter.
And I'm going to also link it here under.
And Dima, could you please share how it improved the user experience, please?
But the only thing I need to correct you, it was the latest release was 1.1.1, not just 1.1.
Yeah, we have like the weekly basis of the releases inside the core repo.
And it's always interesting for tech guys to come to our GitHub and check it out.
So, for example, for each release, we have a set of commits we would like to include into
And there is always release notes with, you know, plenty of letters, plenty of tech letters
with explaining everything about this release.
So speaking of other releases, every release has its own unique stuff.
Some may be contain more changes, while others may have fewer.
Some only focuses on internal invisible implementations, details and so on, while others
can concentrate exclusively on user experience and user space libraries.
So the latest release 1.1.1 was focused on improving the user experience, mostly.
For example, Tix was implemented for Creates.io, it's a website for Rust packages to be
published, where all of the gear libraries published as well, and you can like download
Moreover, there is a new CLI utility for managing your key players was implemented
in order to add it to Creates.io as well.
Speaking of other stuff in the runtime, if you're not mistaken, it was in the last release
and your API related to your vouchers was successfully being introduced.
The new API allows your vouchers that have been issued to you to be rejected by you.
So this addition enhances the overall experience of implementing certain DApps, such as
Stylus and Gasless scenarios, for example.
And speaking of these scenarios, this new functionality was a request by the community
that we were implementing these scenarios.
So if I'm not mistaken, also in the last release was included portable or instrumentation.
It's, you know, it's kind of extra recovery position was added to the gear protocol and the
It's like the process that involves depting of the program's code already uploaded to the
And it's from now on recognized as fallible and its errors will be handled correctly, properly,
which was previously deemed impossible just because there were like assumption that it
always portable for already loaded programs that was like really significantly restricting
new things to be implemented in the runtime.
So now we don't have such invariant.
We can monitor some errors, for example, monitor some compatibility.
These already uploaded programs in future.
So I guess the soul was about the latest release and the next, for example, as I already
said before, will be about the framework for built-in actors and some other good stuff for
runtime of the gear protocol.
Yes, yes, I was I apologize.
So we but we also have we are publishing like a technical monthly update and then the
releases. So these are like two different articles.
So just to clear this confusion and also I published the release article under this
spaces. So if that was interesting for you and you would like to dive into details, you
can. And I think we're going to go for the last question of this AMA, which is actually
And it's about governance.
So that could you explain the governance?
Is it only fellowship voting?
Are there any other real waters and how to become part of fellowship if it's possible?
Yeah, this is a great question.
And governance topic is very huge, but I'll try my best to share my understanding of the
viral governance with you.
So let's begin with what is governance itself.
What is governance is the decentralized system that allows any viral token holder to participate
in the decision making process through the front on chain governance mechanism.
The governance model is based on the open gov framework, which we can see in the polka
dot or any substrate based chains and aims to ensure that the viral community is
represented, led and engaged in decision making processes to collaborative collaboratively
decide the direction of the network.
The governance model allows any viral token holder to propose, discuss and vote on
proposals that can update or modify the network.
Proposals are tied to specific changes to the viral network, including value for key
parameters, code upgrades or changes to the governance system itself or, for example,
So this is all like can could be changed by the governance.
So the proposal process involves several stages, including a lead in period, a
designing period and enactment period.
This is all this all like can can be configured with a proposal like planning you
submitted and proposals must meet a certain criteria to move from one stage to the next,
such as receiving enough votes and meeting the minimum approval and support their
shows. So, for example, there are different tracks in our governance.
For example, with the root track, you can do anything on chain like the privilege of
the privileged user, but it has to meet a very, very big
So like the health of this supply should be voted to to enact this proposal.
And we have different tracks for the staking parameters that are like
different limits and approvals, approvals.
So on the next, the fellowship fellowship is a group of community members who have
special voting rights within the government system.
But I want to mention that fellowship is not related to the global referendum
palette. For example, fellowship members cannot do anything by themselves.
They can vote for, for example, white list proposals.
So the main thing that fellowship does, they can add certain proposals to the white
listed track, which allows for faster voting and approval times.
Fellowship members are chosen based on their contribution to the network and their
expertise in the relevant areas.
And about other real voters, so we have like fellowship member, membership and other
So any VAR token holder can participate in VAR decentralized governance and vote on
proposals. The more tokens a voter holds, the more voting power they have.
Additionally, voters can trade their votes in power by locking up their tokens for a
longer period, which increases their conviction and the weight of their vote.
So the first part is like the fellowship members can like fast track some proposal,
for example, runtime upgrade or changing some network parameters.
And they the next thing they open up a referendum proposal with a white listed
color, the white list track, and anyone can vote for this proposal in the global
referendum. So how to become part of the fellowship?
Currently, the fellowship consists of the gear protocol contributors.
This is because they have deep knowledge about the runtime and can be trusted.
That's a group of people, for example, me and Dima are fellowship members.
And each time we do runtime upgrades, like communicate with each other and submitting
proposals for the fellowship.
And after the runtime upgrade, we will be submitted for global referendum.
So, however, the goal is to eventually expand the fellowship to include other trusted
community members who have demonstrated their expertise and commitment to the network, for
example, outside collaborators, contributors, and to make our network decentralized and
All right. Thanks, Vadim.
I think you covered this topic very well, since we all know how governance it's very
It's much harder than I just discussed, but I tried to cover like basic things.
Yeah, if you're not against, can I make like small sum up the main idea of the fellowship
for our listeners, that the fellowship is not about executing anything on chain.
The fellowship is a set of people who is responsible, a kind of responsible for the
commitments to our network.
And the fellowship mechanism is only speeding up mechanism.
So nothing will be without referendum, without real tokens voted, especially speaking of
criteria and the proposals.
So especially speaking of fellowship proposals.
So fellowship allows you to execute something much faster, but you still need approval from
Yeah, basically just a fast-track method to execute some things.
I mean, as you can all see, I think we know that governance is really hard to cover, but
I think Valim did very well to cover at least on the service and then Dima also add the
So like Bar is a decentralized project, so everything is based and decided by the community.
So just, you know, join the channels if you want to be part and make the decisions.
Just to add to that, and we are at the end of these today's AMA.
Before we will like close this session, would you like to guys add something?
Maybe tease us about what other devs are working on or what, you know, is coming some new
feature or what happened last month or just like, would you like to add some something?
I guess it was already explained about something that is being developed for the last month
or anything we are developing right now.
We are focusing at the moment on this stuff about the built-in address referring to my
So a lot of interesting things is going in user space.
We have a dedicated team member that is that are working on a new library across of JSTD,
And I think it's nothing to say right now.
Stay tuned to our updates and we'll like introduce you a new approach of building the
apps on the water network, I guess.
And also, I'd like to mention that I'll be attending subzero event in Bangkok, so anyone
can ask me in person and I'll go out to answer anything at my best.
All right, that's really great news.
So you hear guys, anyone coming to subzero, just step by him and ask him all the questions
He's going to be there just for you.
And that's actually very exciting.
And yeah, I would like to just share maybe some community updates.
So as we mentioned, we published a community monthly article, also technical article.
So they are under this AMA.
What's also interesting that there is currently running a collection for various squad
So if you want to participate, share your ideas, how like the mascot of the bar community
should look like, just make sure to join and share your ideas.
And I don't know if someone joined actually bubbles yesterday, AMA, but he made quite a big
announcement, which I don't know if you are aware, but I was told I can tease a little
So make sure to follow bar socials for today, because there is going to be a big update
shared about Gear Academy.
So I'm not going to say anything more, just this.
So make sure to follow the official announcement as bar twitter, telegram, discord, all the
socials, because it's really cool.
And yeah, so I would like to thank everyone coming.
It was really, really nice session.
It was like a smaller group, but I think it was like it had the family feeling.
And thanks for the demand that you find time to answer this question.
And feel free also to share your closing remarks.
From my side, I guess I would like to thank every listener is here, and just because as far as I
see, we are getting improved from each AMA from from each to another one to the next one.
And the questions become much more interesting, much more technical oriented.
And I guess in future we'll come to this much more often to this AMA sessions, just because there
is a plan for questions from our community about some hard technical stuff, for example, as like
governance, and we can try and improve ourselves in future.
And answer it in the most simple way as we can to reach everyone is understanding what's going
on with Lara, what's going on with web free at all.
Yeah, thank you very much.
Thank you, everyone who listened to us.
Next time will be much more interesting.
And I hope to see another good questions next time and be less nervous and prepared for public
And also, if someone would have any questions, we don't have an open mic for this session.
But maybe if there's going to be interest from you, just ping us and tell us if you would be
interested to have also open session.
And otherwise, if you have any questions, please go to Discord, Telegram and just ask.
We have a support channels and we will answer your question.
So once again, thanks, everyone, for coming and thanks to you guys and see you at the next one.