How to Succeed with Binary Options Trading at Home 2020

A thorough evaluation of the 9/18 PTS update and base changes, as well as almost everything else coming up.

Hello, here’s another round of Esamir Rework reviews. I’ll also cover the Indar base changes, the storm, vehicle balance changes and new infantry gear. I’m not going to touch on outfit resource changes here, since this post is long enough already. I’d like to give shoutouts to aln-isolator , [NWYT]Praefectus, the pilots of [SACA] and everyone else who helped give feedback.
Here’s the image gallery. This time around the bases listed in the document match the order in which they appear in the gallery. https://imgur.com/a/5pd5VFj
Esamir has a new skybox which is much less bright. I can now see vehicle weapon tracers when shooting. This is a long asked for change.
Andvari: 3 points now, 12 min cap with 2 points, 4 mins with 3 points. Consider adjusting the timers.
Ymir: No changes to terrain that I can see. It’s a 12 minute cap with two points owned, and 4 minutes with 3 points. Might consider reducing those slightly.
Apex Genetics has had its wall adjusted somewhat, as well as the rocks surrounding the triple stack. There are now more routes for infantry to enter the base.
Aurora Materials: Sunderer garage and surrounding terrain seem to have been lowered slightly. Also, there’s now a rock at the end of the garage, which reduces the possible angles the bus inside can be shelled from. The slope between the crescent building and the road has had some paths added for infantry. Overall, good changes. However, there’s still one issue here, and that’s the possibility of shelling the triple stack balcony from the ridge NW of the base. Additional purple spikes from the cluster behind the spawn room could be positioned to block this firing angle.
Eastwake Harborage: Point has received a new structure above it. It’s now on the bottom floor of a triple stack that has an expanded balcony around its second floor. This gives point holders a lot of additional cover, but the problems with this base still exist. There’s still a ridiculous distance between spawn room and the point with minimal cover from vehicles/bolters/LAs- a literal Death Valley. The area immediately around point is still extremely harasser friendly and could use some props to obstruct harasser movement. In its current position, the teleporter room is useless since infantry leaving it must still advance through Death Valley. Sundy positions are a bit sketchy, too. Fortunately, I’ve had a long discussion and now believe this base could be fixed with a couple tweaks. Consider replacing the AI turret outside the spawn room with an AV gun. This would discourage excessively aggressive vehicles from camping Death Valley. Likewise, replacing the light vehicle pull with an MBT pull gives defenders a bit more potential firepower, and increases the area attacking vehicles must cover to protect their own vulnerable spawns. This base would also benefit from the moving of primary teleporter room to a point higher up the hill and closer to the point, as shown by squad waypoint in this image: https://i.imgur.com/TuEee9F.png. A second teleporter here at hearts waypoint https://i.imgur.com/JUbXklc.png gives defenders another route into the point without going through Death Valley. At these two locations sunderer garages could be built to create safer spawn points for attackers.https://i.imgur.com/QWblfz4.png https://i.imgur.com/w4HR05n.png
Echo valley: Rocks have been added on the exterior side of the vehicle terminal to give it some cover. However, they aren’t close enough to each other to prevent me from driving through with a Kobalt bus, nor is there anything stopping me from hacking the terminal or using a GSD to get through the shield and then start driving around the base. Placement of a couple rocks in very specific spots would stop this. Secondly, a crate has been placed between bridges to give infantry another path into the point building. It’s a cool concept, but it needs some form of obstruction to prevent me from driving harassers or possibly larger vehicles onto the two bridges and blasting point directly. Thirdly, consider some form of sight blockers on the west wall to reduce the potential for LAs to spawn camp.
Excavion DS-01E: Cover has been placed over both tunnels, which is an excellent change. MBT pulls have been added to this base, though they could stand to be moved slightly closer to the spawn room to deter attackers from hacking them and flooding the base with AI vehicles. A point is located in a long narrow building near the eastern tunnel exit. B is in a triple stack on the south side. C is located immediately west of the drill site. Capture timer is 4 minutes with two points and 1 minute with all 3.
This base is mostly fine, but could do with some small tweaks for increased cover. At A point the point holders have few options for cover inside. There are two small smokestack structures (pictures in gallery) that could be replaced with actual buildings to provide more cover from aircraft for players moving around inside the base. Timers could probably be increased slightly. Overall though it’s in a decent state.
Genudine Gardens: Some props have been added throughout the base that’ll prevent harassers from turboing around like maniacs, but the gigantic hole in the wall in one corner needs to be closed off somewhat to prevent vehicle entry or at least make it more difficult. This base would be fine if that hole were sealed or obstructed better.
Grey Heron: Additional cover has been placed on the side of the staircase leading from spawn to B/C point. The secondary route for defenders has been fleshed out- the door now is high enough to get under, and there is a hole in the floor that allows defenders to drop down to the lower level. Cover has been added on the B side of this base.
For improvements, I still think a roof is needed over the stairs from defender spawn to the lower level. A wall alone won’t stop tanks from shelling it. C could use a bit of cover, but I’m concerned that adding too much will turn it into a fortress. You can enter this base with harassers, so some bollards should be added to each entrance to prevent that.
Jaegers’ fist: Sunderer garage has been added, and the trench has been improved. This base has some odd issues from an infantry perspective, namely that attackers and defenders have the exact same routes to the point, as shown in the gallery. I have no ideas for how this could be improved. I still believe the point needs some kind of roof to block HESH spam and A2G, preferably a solid one to deter LAs from doing C4 bombing.
BL-4 Recovery and Vidar Observation Post both have spawn rooms and light vehicle terminals. This is a pretty good change, allowing closer vehicle pulls and a shorter sundy reinforcement distance for attacks on the surrounding facilities.
Jord Amp Station: More cover has been added around C point. This is a good change, but doesn’t change the fact that A is still inside the station.
Mani Lake: This one has undergone the most terrain edits, and consequently has become a lot less vehicle friendly. The two trenches leading into the base have had barricades installed, allowing infantry to move through but not vehicles. The hills surrounding the base have had their exterior faces steepened significantly, preventing treaded vehicles from driving up them. This change is excellent, but needs a bit of tuning. The Western Ridge’s southern tip has a shallow enough slope that tanks can still drive up it. On the large mountain to the West on the far side of the road, there’s a small protrusion that should also be levelled. Once these two spots are taken care of, this base will be fine. Overall, the changes are very good here.
Mattherson’s Triumph: The Sunderer NDZ has been reduced in radius, which allows the defenders to deploy inside the south tower for a safer position. This is a good change. The ridgeline to the NE has had its northern face steepened significantly, preventing tanks from driving up that side. However, the SW face has become easier to traverse, so the ridge is still usable for bombardment of the catwalks and A point. If this goes live in this state, it’s not a total disaster since tanks driving up that will be very exposed to AV fire from the tower, but it still could stand to be addressed. Likewise, there’s still a nice spur sticking out of the north end from the NW ridge that allows tanks to easily shell defender spawn and A point. The fix here is simple- flatten the spur completely.
A point needs additional work. At minimum, the windows on each tower in the room where A point/SCU would normally go should be sealed off to reduce the angles point holders must watch. There’s very little cover on the ground, especially when you consider all the angles A can be shot at from. I believe the point could be enclosed in the same type of building used at Chimney Rock’s point on Amerish. The bridges are a mixed bag. They’re identical copies with one rotated 180 degrees, which means that crate placement favors the attackers on B side and the defenders on the C side. Picking one crate pattern for all 4 bridge ends is one possible fix. I’m still not sold on the idea of both points being on bridges. They’re very exposed to A2G spam and bolters. Overall, at the very least the terrain edits are a nice start, and the sunderer NDZ change is very welcome.
Nott Communications: This base is now entirely underground. Attackers enter by overloading a shielded gate, and then drop down into an amp station interior. These gravity lifts are one way, but please consider adding an up lift to replace one of the drop pads. A point is in the position where A points usually are in amp stations. B and C are in the room where SCU would be normally positioned. At the end of this room where the tunnels and back door would normally be is a one-way teleporter, which is the only way for anyone to get out of this base right now. Defenders spawn underground and there’s a one-way shield leading to where the vehicle bay normally is. To improve this base, I’d make the one-way shield a two way shield, and reverse one of the grav lifts. I could not test the cap timer since I did not feel like ghost capping half a continent.
Pale Canyon: Some cover has been adjusted by the big yellow tanks on the SE side. A new route has been placed through the rocks at the NW corner of the base. This is an interesting change, but I don’t know how that’ll play out on live since currently I can park a bus inside the base at the same location.
The Rink: The ground texture at A point is now ice, so it’s actually an ice rink. Too bad you don’t slide around here.
Saerro Listening Post: Trees added to A point to break LOS between attacking vehicles and the tower. The wall between A and B has had some new gaps placed in it to allow infantry to get in. Interesting changes for sure, but I don’t know how they’ll play out.
The Traverse: The bridge has been resurrected, although it’s in a heavily damaged state. It’s now an infantry only playground, unless you’re a bold harasser or magrider driver. Because the storm was here, I really couldn’t stick around and take a long look at this. Lastly, the bottom of the pit has been raised a bit and paths to the bottom have been defined more clearly.
There also have been some changes to roads around the continent, but nothing major.
Indar:
TI Alloys: The removal of the bridge is a failure to understand why TI Alloys is such a difficult base to attack. On live servers, TI currently suffers from horrific sunderer placement options which combine with its central location to create a base that’s easy to defend. From the North, attackers must park their bus and attack up a hill through narrow ravines into entrenched defenders backed up by AI harassers, sunderers, ANTs, lightnings and even occasional MBTs. From the South, attackers have two bus spots: One is placed to the south-east, below the point. The other is placed directly south of the spawn room on the far side of the road. Both of these options are suboptimal- on the south east spawn the bus can easily be sniped by vehicles shelling from the Crown, driving down from the Crown, or by vehicles streaming out of the vehicle pull. The south bus on the far side of the road is also not ideal, since infantry have to cross the road and deal with a flood of vehicles as well as an angry AI turret. The only decent spawn location is at the end of the rock bridge, since that one’s reasonably safe from enemy vehicles and doesn’t involve attacking from the low ground. However, this position’s impeded by the fact that attackers from the north inevitably gravitate to the eastern side of the base since that’s safer from the defenders, forcing a three way that never ends. The result is a base that can’t be broken except by routers.
The removal of the rock bridge changes none of this, but instead creates more problems. The safe sundy position on the bridge is gone entirely. Further, the bridge’s removal allows tanks to bombard Ti from the Crown once more, since it served as a line-of-sight blocker. The new attacker foot path to the north east is extremely vulnerable to bombardment from the Crown.
As far as the base interior goes, a new wall has been added to the interior of the point room structure. This might give attackers a better chance to get to the point, but at the same time it might make things easier for the defenders should they conduct an organized push since there are fewer angles to set up a crossfire from.
So how can Ti be improved? I’d start by bringing the bridge back, or at least a small section of it to allow for a safe sunderer position at the east side. For the south, consider a tunnel leading under the road. This allows infantry to get to the base safely. I’d also consider adding in more props to restrict the passage of vehicles through the spawn room area to the northern side of the base. Removing the Kobalt bus fiesta there will make it easier for attackers to push in from the north. Lastly, if the bridge is not restored, consider creating a rock wall at the north east section of crown to prevent tanks from raining hell on anyone fighting at Ti.
Crown: The removal of D point is honestly a good thing. It wasn’t fun for anyone to attack since it’s open ground and below a cliff which enables C4 spam against vehicles and requires attackers push against entrenched infantry. Since Crown becomes a three point again, now the base cannot be stuck in a perpetual stalemate. I’m not a fan of where A point was moved to, either. I think if the rock bridge were kept then Crown would be mostly fine. With the three non-vehicle points it has on live. The issue with A being on that southern bridge is that if the attackers set up sunderers to control B, then they get A almost for free and can contest C as well. B point has been moved farther towards the center of the mountain and the tunnel system lengthened a bit, and a lot of cover has been removed at the initial entrance room that exists on live.The extra tunnel into B is an interesting idea and gives a better chance of an attack from the North succeeding, but at the same time it’s just another tunnel choke point to for aoe spam to create nasty farms. C is also problematic if it’s supposed to be the easy point for defenders to contest. It’s a fair distance from the tower, and it’s also open ground which is prime for A2G farming. I’d suggest moving this one into one of the nearby buildings if A must stay in the position it’s at on PTS. I’m not convinced the base needed any point position changes apart from the removal of D point. The current point layout on PTS favors an attack from the SE very heavily, and attacks from the East or North are far more difficult. While old A was very close to the tower, at least it provided a convenient point for attacks from the East. None of the changes really address the problem of poor bus location options, and with the current terrain there really aren’t many good potential spawn options. At most some garages could be added.
Ceres Hydroponics: Defenders now have a slightly shorter path to the point when pushing from the NE side of the base. The point itself has much less cover. I’m not going to make judgements on this without seeing how it plays out.
The Esamir storm: I’m not sure what this thing is supposed to do. The entire point of the game is large scale battles, yet this thing rolls around the map destroying the biggest fights. There’s nowhere safe from it. Sunderers will get destroyed even if put in garages. When outdoors infantry can be instagibbed by lightning for staying outside too long, and even when indoors their shielding takes frequent chip damage from environmental effects. The shield damage consistently drops players down about 150 shield points that constantly recharge, but this is enough to start messing with TTKs. For example, a commissioner can consistently OHK players. Since the shield damage is not synchronized across all players, it’s possible to be forced into gunfights where you have no hope of winning not because you were in a bad spot or outplayed, but simply because the game decided it’s your time to die. This applies doubly for lightning bolts which will randomly strike you down. There’s a text warning, of course, but random OHK mechanics really shouldn’t be a thing. You cannot use steel rain in the storm.
For vehicles this is obnoxious too. Ground vehicles lose most of their mobility, which will punish new players with poorly certed vehicles even more. Aircraft are even worse off, losing most of their vertical thrust. At times I felt like even afterburning upward was barely enough to keep the aircraft airborne. Vehicles kept in the storm for too long will simply be instagibbed, which cripples sunderers as spawns. The storm also destroys base turrets and terminals.
There are counters to the storm, though. Infantry can deploy lightning rods bought with merit that allow them to fight outside, but it doesn’t stop shield chip damage, and can equip an insulated armor suit at the cost of flak armor, nanoweave, or shield capacitor. This suit slot appears to be bugged and doesn’t actually reduce the chip damage taken by your shields. Carapace seems to be immune to this chip damage. Vehicles can equip insulated armor in the defense slot. This mitigates the performance hit to vehicles, reduces the damage taken by lightning, and prevents the storm from instagibbing your vehicle. Now, this is less of a problem in the first place for aircraft and tanks, but it screws over sunderers. Sunderers are already fragile enough even with deployment shield equipped, but forcing spawn buses to use this module and rely on their low hull HP is a very bad idea when paired with random lightning strikes and the severe lack of garages Esamir has.
With all that out of the way, the question I have to ask is why is the storm designed like this? It seems like a band-aid fix for zerging and actively punishes trying to create large fights. It cripples the vehicle game, negatively affects the infantry game, creates inconsistent TTKs, and only adds frustrating game mechanics. If the center of the map ends up with stalemates, it’ll circle around there endlessly preventing any kind of progress through the pile of three point bases. Why this, when there’s a lot more interesting concepts that could be used? For example, maybe the storm could reduce the rate at which players can spawn at a base/sunderers/routers. Maybe it could jam radaprevent Q spotting. Consider reducing shield chip damage to 50 shields instead of 150 to reduce TTK variance. There’s a lot more interesting ways it could change the game without being the anti-fun mechanic that it’s currently set up as.
Infantry gear:
Lightning grenade: Cool, you can launch a targeted lightning strike when in the storm. More instagibs is what the game needed.
Lightning rod: This temporarily redirects lightning strikes near you. This is a solution to an obnoxious problem that doesn’t need to exist.
Condensate grenade: Reduces movement speed and ROF by 20% for six seconds. This is a terrible idea in an FPS game. This doesn’t create interesting gameplay situations. Instead of being outplayed, players hit by this just lose since the game’s punishing them for playing. Keep this in RPGs and RTS games. Now, we do have status grenades already, but do we need one that’s as powerful as this one is?
BEC grenade: Similar to Condensate Grenades, this is a horrible addition to the game. Anything that hurts player mobility/damage output is a bad idea.
Neutralizer Device: Campaign reward that allows players to acquire abandoned vehicles, and apparently strip ability energy from players too. I like the idea of vehicle acquisition, but I don’t know if we’ll ever see the second use of this tool.
Abandoned vehicles: Around the continent are the hulks of abandoned tanks, sunderers and aircraft. They come with a special ability that I haven’t really tested, HEAT cannons and the first generation ES top gun. For the sake of loadout parity for all 3 abandoned MBTs I’d like to suggest the Prowler get a Gatekeeper instead of the Vulcan.
Vehicle changes: Havoc missiles: Are these things still necessary, with the liberator nerfs? These things seem redundant now, and they’ll punish rep gal balls unnecessarily hard while valkyries with rep monkeys can probably still dodge these things easily.
Phalanx AA turret range increase: This doesn’t fix any of the problems with the current AA setup. Instead, it’s going to just annoy A2A players who are flying along at high altitude and getting plinked by base AA guns, which is the reason the things got their range capped to begin with! Honestly I think these things should be replaced by weapons like Bastion CIWS guns. Those things are nasty at close range but their damage output falls off heavily at range.
Liberator: -500 HP and ESF nosegun resist from 85 to 80. While the liberator needed some changes regarding its durability and repair tanking in particular, this change spectacularly misses the mark on many levels. This change skews ESF vs Liberator combat too far in favor of ESFs. When paired with air locks this brings down the TTK to incredibly fast levels (around 9 seconds, which isn’t even enough for three dalton shots) In this post, mystoganofedolas https://www.reddit.com/Planetside/comments/ivjg8t/rock_paper_scissor_balance/ explains in great detail the liberator issues- it’s a blatant hard counter to ground vehicles, and gets brutally hard countered by ESFs on PTS. Hard counter mechanics are terrible in an FPS game. In this sort of rock-paper-scissors gameplay, things boil down less to individual ability and more towards who has an exact counter to something, which is extremely boring. There’s no skill in using A2A missiles, just as there’s minimal skill in hovering over tanks and daltoning them. In this post here https://www.reddit.com/Planetside/comments/ivsssx/did_some_basic_math_regarding_the_upcoming/, taltharius demonstrates that -500 HP barely changes anything in the case of liberators eating multiple AP shells before hitting fire suppression and flying off. Skilled gunnery should be rewarded, and sloppy flying should be punished.
So how can this be improved? Consider reducing vulnerability to ESF noseguns slightly. Adjusting Liberator resistance against tank shells, light anti-vehicle, gatling guns, and infantry rockets will increase the damage libs take from ground fire and punish poor flying/reward skilled aim. Possibly consider increasing MBT main gun elevation angles slightly, to reduce the ability of liberators to hover over tanks with minimal counterplay.
Harasser: Nanite cost to 300. Oh boy this one misses the mark completely. The problem with harassers has never really been cost related, but rather one that got introduced with CAI. The harasser itself is not overpowered and its efficiency in combat drops off hard at higher levels of gameplay. Only when harasser numbers become overwhelming (3 or more harassers vs 1 MBT) do the harassers stand a chance of defeating the best tank crews, and even then the tank usually can take 2-3 harassers with it. Harasser vs tank gameplay is extremely boring and very binary. If the harasser has a CQ AV gun it’s forced to fight at point blank which means I delete it easily. If it uses halberd or ES long range AV we both enter a boring poke fight where neither one does significant damage to the other. Even if the harasser opens up with rear hits the MBT still has an overwhelming advantage in firepower and hit points. With tanks, the problem since CAI has been poor muzzle velocity of HEAT shells which makes hitting difficult and what most players will have equipped, pathetic Basilisk DPS against everything (Kobalt kills stock harassers 4 seconds faster), Skyguards being helpless against every ground vehicle, and the Viper not having the accuracy to deal with small moving fast targets. Small changes to these three weapons will reduce harasser vs tank complaints.
Harasser vs Harasser is broken, for a different reason. Harassers have a weakness to gatling guns, which means that the Vulcan and Aphelion rip through harassers while the Mjolnir specializes in fighting heavy vehicles. In practice, this means that for low/average skilled car crews, vulcans are disproportionately powerful since less skilled players won’t know to keep outside minimum damage range. At higher levels an Aphelion car is very hard to fight. Toning back harasser weaknesses to gatling guns might improve this situation, but at the same time it might nerf the Aphelion too much. At the very least this’d probably reduce vulcan whine somewhat.
Overall, I have mixed impressions. The base changes are mostly for the better, but the storm, infantry gear, and vehicle changes are mostly bad or miss the mark completely.
submitted by ItsJustDelta to Planetside [link] [comments]

Giving Props To THUGPro

Alright, so this is only my third post here on Reddit. But I wanted to air some opinions of mine, after picking up Tony Hawk 1+2 a few days back.
A couple months ago, I came across the THUGpro mod for Underground 2, and really liked all of the amazing features they added as far as customisation goes. For example, the customisation options weren't actually as limited as they are in the new polished remaster. You could add sunglasses, "hat hair", and a plethora of different apparel items that just aren't all there in the newest game.
Now, I can comfortably say that the 1+2 remaster is phenomenal! At least in my opinion. I feel like I've only gotten better at TH games since I picked it up, and I was never a good player to begin with. The lighting is beautiful, and really gives levels like Warehouse and Venice Beach the chance to play into their individual vibe a whole lot more. I especially enjoyed the little details such as the cars on Downtown - Back in the older games (if memory serves right) the little taxi cabs would still cruise around the map, but they would make awkward 90 degree turnarounds. For the time, that was still an "OMG Ttyl watching history take place" type of deal, but in the remaster I was blown away when I saw the cars actually drifting and swerving around corners and whatnot.
But beyond all of it, all of the techical implementations and downright killer adjustments, I still feel as if THUGPro needs some major props. This was a mod that enabled you to have the best of both worlds - The responsive, fluid control scheme from the Underground games, coupled with the ability to freely select levels from almost every game in the series. And a lot of the stuff that wasn't there in the beginning was added in later updates. Another thing I always enjoyed was that in THUGPro, every time I played no two characters looked the same. In fact, some of the more "veteran" players I was able to recognise because their characters style kind of became their trademark!
All the way back in 2013, the Tony Hawk series last 3 entries were by RoboModo. They were Tony Hawk Ride (2009), Tony Hawk Shred (2010) and Tony Hawk's Pro Skater HD from 2012. I'm not going to be "that guy" and trash these games, because there are a lot of videos and posts already doing that.
What I will say is that THUGPro - at least in my opinion, played an absolutely crucial role in holding onto and even growing a player base of fans who love the Tony Hawk games. That's something to be celebrated. The people who worked on that mod, those are the dudes and dudettes and non-binary-dudes who kept something going through some very uncertain times. And while I was never amazing at THUGPro (I'm being generous, I don't think I ever won a single game of Trick Attack) the point I guess I'm trying to make is that I feel the community owes that development team some props.
Not sure if I've been speaking out of turn here, and I'm confident that there are people on this Subreddit that probably know a great deal more about this sort of thing than I do, but I think that the Tony Hawk community, (and skating game communities for that matter) seem to have a very chill and friendly userbase. I figured I'd throw a little appreciation in the direction of the modders, and let them know that their work is still appreciated!
Rock on everybody, stay safe and don't smoke, or if you do smoke, don't be like me and tell people on Reddit not to smoke when you're literally picking up your cigarettes and lighter and humming Pearl Jam as you walk outside to contradict yourself. \m/
TL;DR Loving the new Tony Hawk 1+2, but wanted to give props to THUGPro development team because they played a part in keeping the community together through uncertain times.
submitted by DeadlyPremonitions to THPS [link] [comments]

[TUTORIAL] How to use Multi-Monitors with Hybrid Graphics Card Intel-Nvidia in notebooks (tried with: Asus Rog Strix G531-GT) - DEBIAN BUSTER

Hello guys! I`m going to do this tutorial because i tried to use multi-monitor in my laptop for a long time and that was a big problem for my case.
This tutorial is for people who have a hybrid graphics card and bumblebee in debian.
My case:
- Rog Strix G531-GT (notebook)
- Intel® UHD Graphics 630
- GTX 1650

So, to it work, first you need to install all the NVIDIA drivers and get it working with the optirun command.
In my case i tried stable nvidia drivers which was Version 418.152, but it have some bugs after install when i tried to configure the xorg.conf file, which when start says something about missing device "mouse0". I reinstall all the debian and tried to use the backports, which have the Version 440.100 (via buster-backports) of nvidia drivers, and it installed well.
#ONLY USE BACKPORTS OR ONLY USE STABLE, DO NOT USE BOTH!
FIRST, VERY IMPORTANT: You should check which driver is okay for you, maybe trying one, if that is good and u dont see "bugs" when trying to configure, use it... In my case 418.152 give me a lot of bugs... i tried 440.100 and it worked ok. If you are using backports, try to download everything at the BACKPORTS, and not the STABLE one! If u are using the STABLE one, continues using the STABLE
To do it, first add the backport repository to /etc/apt/sources.list, which actually is
deb http://deb.debian.org/debian buster-backports main contrib non-free
deb-src http://deb.debian.org/debian buster-backports main contrib non-free

After that, to install linux headers and nvidia-driver do:
- apt update
- apt install -t buster-backports linux-headers-amd64
- apt install -t buster-backports nvidia-driver


Reboot and after that u already have the nvidia-drivers installed, BUT not working because the system dont use the nvidia driver by default. Next step is installation of two packages: bumblebee-nvidia and primus. So now you need to install bumblebee:
- apt install -t buster-backports bumblebee-nvidia primus
- apt install -t buster-backports mesa-utils \you will need the) mesa-utils too for some commands
I didnt need permissions to use the bumblebee commands, but if you need, follow that Post-installation


You may need to blacklist the nouveau drivers, because we are using the nvidia proprietary drivers. To do it, run:
- $ sudo bash -c "echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
- $ sudo bash -c "echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
then run
- $ cat /etc/modprobe.d/blacklist-nvidia-nouveau.conf
And the output should be like that:
blacklist nouveau
options nouveau modeset=0
The nouveau drivers are blacklisted successfully!


Now we have a lot of configurations to do.
The next thing to do is go to /etc/bumblebee/bumblebee.conf and open with nano.
add - Driver=nvidia
it should looks like:
# Configuration file for Bumblebee. Values should **not** be put between quotes ## Server options. Any change made in this section will need a server restart # to take effect. [bumblebeed] # The secondary Xorg server DISPLAY number VirtualDisplay=:8 # Should the unused Xorg server be kept running? Set this to true if waiting # for X to be ready is too long and don't need power management at all. KeepUnusedXServer=false # The name of the Bumbleblee server group name (GID name) ServerGroup=bumblebee # Card power state at exit. Set to false if the card shoud be ON when Bumblebee # server exits. TurnCardOffAtExit=false # The default behavior of '-f' option on optirun. If set to "true", '-f' will # be ignored. NoEcoModeOverride=false # The Driver used by Bumblebee server. If this value is not set (or empty), # auto-detection is performed. The available drivers are nvidia and nouveau # (See also the driver-specific sections below) Driver=nvidia # Directory with a dummy config file to pass as a -configdir to secondary X XorgConfDir=/etc/bumblebee/xorg.conf.d # Xorg binary to run XorgBinary=/uslib/xorg/Xorg ## Client options. Will take effect on the next optirun executed. [optirun] # Acceleration/ rendering bridge, possible values are auto, virtualgl and # primus. Bridge=auto # The method used for VirtualGL to transport frames between X servers. # Possible values are proxy, jpeg, rgb, xv and yuv. VGLTransport=proxy # List of paths which are searched for the primus libGL.so.1 when using # the primus bridge PrimusLibraryPath=/uslib/x86_64-linux-gnu/primus:/uslib/i386-linux-gnu/primus # Should the program run under optirun even if Bumblebee server or nvidia card # is not available? AllowFallbackToIGC=false # Driver-specific settings are grouped under [driver-NAME]. The sections are # parsed if the Driver setting in [bumblebeed] is set to NAME (or if auto- # detection resolves to NAME). # PMMethod: method to use for saving power by disabling the nvidia card, valid # values are: auto - automatically detect which PM method to use # bbswitch - new in BB 3, recommended if available 

After that, go to /etc/bumblebee/xorg.conf.nouveau and open with nano.
add - BusID "", ex. BusID "PCI:00:02:0" in the Section "Device" \ to see the ID of your graphic cards, run in console: lspci | egrep 'VGA|3D')
it should looks like:
# Configuration file for Bumblebee. Values should **not** be put between quotes ## Server options. Any change made in this section will need a server restart # to take effect. [bumblebeed] # The secondary Xorg server DISPLAY number VirtualDisplay=:8 # Should the unused Xorg server be kept running? Set this to true if waiting # for X to be ready is too long and don't need power management at all. KeepUnusedXServer=false # The name of the Bumbleblee server group name (GID name) ServerGroup=bumblebee # Card power state at exit. Set to false if the card shoud be ON when Bumblebee # server exits. TurnCardOffAtExit=false # The default behavior of '-f' option on optirun. If set to "true", '-f' will # be ignored. NoEcoModeOverride=false # The Driver used by Bumblebee server. If this value is not set (or empty), # auto-detection is performed. The available drivers are nvidia and nouveau # (See also the driver-specific sections below) Driver=nvidia # Directory with a dummy config file to pass as a -configdir to secondary X XorgConfDir=/etc/bumblebee/xorg.conf.d # Xorg binary to run XorgBinary=/uslib/xorg/Xorg ## Client options. Will take effect on the next optirun executed. [optirun] # Acceleration/ rendering bridge, possible values are auto, virtualgl and # primus. Bridge=auto # The method used for VirtualGL to transport frames between X servers. # Possible values are proxy, jpeg, rgb, xv and yuv. VGLTransport=proxy # List of paths which are searched for the primus libGL.so.1 when using # the primus bridge PrimusLibraryPath=/uslib/x86_64-linux-gnu/primus:/uslib/i386-linux-gnu/primus # Should the program run under optirun even if Bumblebee server or nvidia card # is not available? AllowFallbackToIGC=false # Driver-specific settings are grouped under [driver-NAME]. The sections are # parsed if the Driver setting in [bumblebeed] is set to NAME (or if auto- # detection resolves to NAME). # PMMethod: method to use for saving power by disabling the nvidia card, valid # values are: auto - automatically detect which PM method to use # bbswitch - new in BB 3, recommended if available # switcheroo - vga_switcheroo method, use at your own risk # none - disable PM completely # https://github.com/Bumblebee-Project/Bumblebee/wiki/Comparison-of-PM-methods ## Section with nvidia driver specific options, only parsed if Driver=nvidia [driver-nvidia] # Module name to load, defaults to Driver if empty or unset KernelDriver=nvidia PMMethod=auto # colon-separated path to the nvidia libraries LibraryPath=/uslib/x86_64-linux-gnu/nvidia:/uslib/i386-linux-gnu/nvidia:/uslib/x86_64-linux-gnu:/uslib/i386-linux-gnu # comma-separated path of the directory containing nvidia_drv.so and the # default Xorg modules path XorgModulePath=/uslib/nvidia,/uslib/xorg/modules XorgConfFile=/etc/bumblebee/xorg.conf.nvidia # If set to true, will always unload the kernel module(s) even with # PMMethod=none - useful for newer Optimus models on which the kernel power # management works out of the box to power the card on/off without bbswitch. AlwaysUnloadKernelDriver=false ## Section with nouveau driver specific options, only parsed if Driver=nouveau [driver-nouveau] KernelDriver=nouveau PMMethod=auto XorgConfFile=/etc/bumblebee/xorg.conf.nouveau 

Do the same in /etc/bumblebee/xorg.conf.nvidia, and put the ID of the Discrete Nvidia Card.
add - BusID ""
add - Option "AllowEmptyInitialConfiguration" "true"
and at the END of the file, add
Section "Screen" Identifier "Screen0" Device "DiscreteNVidia" EndSection 
it should look like:
Section "ServerLayout" Identifier "Layout0" Option "AutoAddDevices" "true" Option "AutoAddGPU" "false" EndSection Section "Device" Identifier "DiscreteNvidia" Driver "nvidia" VendorName "NVIDIA Corporation" # If the X server does not automatically detect your VGA device, # you can manually set it here. # To get the BusID prop, run `lspci | egrep 'VGA|3D'` and input the data # as you see in the commented example. # This Setting may be needed in some platforms with more than one # nvidia card, which may confuse the proprietary driver (e.g., # trying to take ownership of the wrong device). Also needed on Ubuntu 13.04. BusID "PCI:01:00:0" # Setting ProbeAllGpus to false prevents the new proprietary driver # instance spawned to try to control the integrated graphics card, # which is already being managed outside bumblebee. # This option doesn't hurt and it is required on platforms running # more than one nvidia graphics card with the proprietary driver. # (E.g. Macbook Pro pre-2010 with nVidia 9400M + 9600M GT). # If this option is not set, the new Xorg may blacken the screen and # render it unusable (unless you have some way to run killall Xorg). Option "ProbeAllGpus" "false" Option "AllowEmptyInitialConfiguration" "true" Option "NoLogo" "true" Option "UseEDID" "true" # Option "UseDisplayDevice" "none" EndSection Section "Screen" Identifier "Screen0" Device "DiscreteNVidia" EndSection 
REBOOT NOW, IS IMPORTANT!!


At this point, the TEST for bumblebee should be working!
Test
Install mesa-demos and use glxgears to test if if Bumblebee works with your Optimus system:
$ optirun glxgears -info
If it fails, try the following commands:
64 bit system:
$ optirun glxspheres64
32 bit system:
$ optirun glxspheres32
If the window with animation shows up, Optimus with Bumblebee is working.
Note: If glxgears failed, but glxspheresXX worked, always replace "glxgears" with "glxspheresXX" in all cases.
If the bumblebee still not working, you should look why isnt it working. You can ask me maybe i can help with some information! I tried a lot of things and maybe i can help.
now finally, you can run anything with the optirun command, like: optirun virtualbox... or optirun (a game) and it will work with you graphic card.
But still, when you connect a monitor at the HDMI output, the monitor will not work...
For that, finnaly, we can do that:
To use multi monitors, we need to see this section, which is what happen to me: Output wired to the NVIDIA chip
At this point, you may need to configure the /etc/X11/xorg.conf.d/20-intel.conf
and /etc/bumblebee/xorg.conf.nvidia, as it says in the tutorial. After that reboot your system and try again the command: optirun intel-virtual-output
It should finally works, if you have connected another monitor in HDMI output and try the command optirun intel-virtual-output, it will start in the monitor a continuation for the X session, which works pretty well!!

Well, that was hard to do for me, and i hope that information can help someone. If something is confusing or you cant do the second monitor work, just type in comments, i will try to help...

One important thing to do is: do not try to use xorg.conf file, just delete it and keep the linux to do it by itself. Every time which i tried to use the xorg.conf file it broke my gnome startup and i need to start debian in recovery mode and go to /etc/X11, and run rm -R xorg.conf (which delete the xorg file), or rename it to the linux do not read the informations there.
#TIPS: For a good use of that, you can go to debian keyboard configuration, and configure a new shortcut with the command optirun intel-virtual-output.
When you press ctrl+alt+y that will start the second monitor for you :D
https://preview.redd.it/3luethknnfj51.png?width=987&format=png&auto=webp&s=a7eaf1a4c029237fd9b25ca0194c99d84fcb83a5
so that is #learning_with_linux
thanks

https://preview.redd.it/8g753mxelfj51.jpg?width=4032&format=pjpg&auto=webp&s=1d24f618dcd3bb92a760a531112e5e3852e524d5
submitted by MrMineToons to debian [link] [comments]

ShardingSphere 4.x Orchestration - Data Masking

Background

Security control has always been a crucial link of orchestration; data masking falls into this category. For both Internet enterprises and traditional sectors, data security has always been a highly valued and sensitive topic. Data masking refers to transforming some sensitive information through masking rules to safely protect the private data. Data involves client's security or business sensibility, such as ID number, phone number, card number, client number and other personal information, requires data masking according to relevant regulations.
Because of that, ShardingSphere has provided data masking, which stores users' sensitive information in the database after encryption. When users search for them, the information will be decrypted and returned to users in the original form.
ShardingSphere has made the encryption and decryption processes totally transparent to users, who can store desensitized data and acquire original data without any awareness. In addition, ShardingSphere has provided internal masking algorithms, which can be directly used by users. In the same time, we have also provided masking algorithm related interfaces, which can be implemented by users themselves. After simple configurations, ShardingSphere can use algorithms provided by users to perform encryption, decryption and masking.

Preface

Apache ShardingSphere is an ecosystem of open source distributed database middleware solutions. It consists of Sharding-JDBC, Sharding-Proxy, and Sharding-Sidecar (in planning) which are independent of each other, but can be used in mixed deployment. All of these can provide standardized data sharding, distributed transactions, and distributed governance functions, and can be applied to various situation such as Java homogeneous, heterogeneous languages, containers, cloud native, and so on.
The data encryption module belongs to the sub-function module under the core function of ShardingSphere distributed governance. It parses the SQL input by the user and rewrites the SQL according to the encryption configuration provided by the user, thereby encrypting the original data and storing the original data and store the original data (optional) and cipher data to database at the same time. When the user queries the data, it takes the cipher data from the database and decrypts it, and finally returns the decrypted original data to the user. Apache ShardingSphere distributed database middleware automates and transparentizes the process of data encryption, so that users do not need to pay attention to the details of data decryption and use decrypted data like ordinary data. In addition, ShardingSphere can provide a relatively complete set of solutions for the encryption of online services or the encryption function of new services.

Demand Analysis

The demand for data encryption is generally divided into two situations in real business scenarios:
  1. When the new business start to launch, and the security department stipulates that the sensitive information related to users, such as banks and mobile phone numbers, should be encrypted and stored in the database, and then decrypted when used. Because it is a brand new system, there is no inventory data cleaning problem, so the implementation is relatively simple.
  2. For the service has been launched, and plaintext has been stored in the database before. The relevant department suddenly needs to encrypt the data from the on-line business. This scenario generally needs to deal with three issues as followings:
    a) How to encrypt the historical data, a.k.a.s clean data.
    b) How to encrypt the newly added data and store it in the database without changing the business SQL and logic; then decrypt the taken out data when use it.
    c) How to securely, seamlessly and transparently migrate plaintext and ciphertext data between business systems

Detailed Process

Overall Architecture

Encrypt-JDBC provided by ShardingSphere are deployed with business codes. Business parties need to perform JDBC programming for Encrypt-JDBC. Since Encrypt-JDBC implements all JDBC standard interfaces, business codes can be used without additional modification. At this time, Encrypt-JDBC is responsible for all interactions between the business code and the database. Business only needs to provide encryption rules. ** As a bridge between the business code and the underlying database, Encrypt-JDBC can intercept user behavior and interact with the database after transforming the user behavior. ** ![1](https://shardingsphere.apache.org/document/current/img/encrypt/1_en.png)
Encrypt-JDBC intercepts SQL initiated by user, analyzes and understands SQL behavior through the SQL syntax parser.According to the encryption rules passed by the user, find out the fields that need to be encrypted/decrypt and the encryptodecryptor used to encrypt/decrypt the target fields, and then interact with the underlying database.ShardingSphere will encrypt the plaintext requested by the user and store it in the underlying database; and when the user queries, the ciphertext will be taken out of the database for decryption and returned to the end user.ShardingSphere shields the encryption of data, so that users do not need to perceive the process of parsing SQL, data encryption, and data decryption, just like using ordinary data.

Encryption Rule

Before explaining the whole process in detail, we need to understand the encryption rules and configuration, which is the basis of understanding the whole process. The encryption configuration is mainly divided into four parts: data source configuration, encryptor configuration, encryption table configuration, and query attribute configuration. The details are shown in the following figure: ![2](https://shardingsphere.apache.org/document/current/img/encrypt/2_en.png)
Datasource Configuration:The configuration of DataSource.
Encryptor Configuration:What kind of encryption strategy to use for encryption and decryption. Currently ShardingSphere has two built-in encryption/decryption strategies: AES / MD5. Users can also implement a set of encryption/decryption algorithms by implementing the interface provided by ShardingSphere.
Encryption Table Configuration:Show the ShardingSphere data table which column is used to store cipher column data (cipherColumn), which column is used to store plain text data (plainColumn), and which column users want to use for SQL writing (logicColumn)
How to understand Which column do users want to use to write SQL (logicColumn)?
We can understand according to the meaning of Encrypt-JDBC. The ultimate goal of Encrypt-JDBC is to shield the encryption of the underlying data, that is, we do not want users to know how the data is encrypted/decrypted, how to store plaintext data in plainColumn, and ciphertext data in cipherColumn. In other words, we do not even want users to know the existence and use of plainColumn and cipherColumn. Therefore, we need to provide users with a column in conceptual. This column can be separated from the real column of the underlying database. It can be a real column in the database table or not, so that the user can freely change the plainColumn and The column name of cipherColumn. Or delete plainColumn and choose to never store plain text and only store cipher text. As long as the user's SQL is written according to this logical column, and the correct mapping relationship between logicColumn and plainColumn, cipherColumn is given in the encryption rule.
Why do you do this? The answer is at the end of the article, that is, to enable the online services to seamlessly, transparently, and safely carry out data encryption migration.
Query Attribute configuration:When the plaintext data and ciphertext data are stored in the underlying database table at the same time, this attribute switch is used to decide whether to directly query the plaintext data in the database table to return, or to query the ciphertext data and decrypt it through Encrypt-JDBC to return.

Encryption Process

For example, if there is a table in the database called t_user, there are actually two fields pwd_plain in this table, used to store plain text data, pwd_cipher, used to store cipher text data, and define logicColumn as pwd. Then, when writing SQL, users should write to logicColumn, that is, INSERT INTO t_user SET pwd = '123'. ShardingSphere receives the SQL, and through the encryption configuration provided by the user, finds that pwd is a logicColumn, so it decrypt the logical column and its corresponding plaintext data. As can be seen that ** ShardingSphere has carried out the column-sensitive and data-sensitive mapping conversion of the logical column facing the user and the plaintext and ciphertext columns facing the underlying database. **As shown below:
![3](https://shardingsphere.apache.org/document/current/img/encrypt/3_en.png)
** This is also the core meaning of Encrypt-JDBC, which is to separate user SQL from the underlying data table structure according to the encryption rules provided by the user, so that the SQL writter by user no longer depends on the actual database table structure. The connection, mapping, and conversion between the user and the underlying database are handled by ShardingSphere. ** Why should we do this? It is still the same : in order to enable the online business to seamlessly, transparently and safely perform data encryption migration.
In order to make the reader more clearly understand the core processing flow of Encrypt-JDBC, the following picture shows the processing flow and conversion logic when using Encrypt-JDBC to add, delete, modify and check, as shown in the following figure. ![4](https://shardingsphere.apache.org/document/current/img/encrypt/4_en.png)

Detailed Solution

After understanding the ShardingSphere encryption process, you can combine the encryption configuration and encryption process with the actual scenario. All design and development are to solve the problems encountered in business scenarios. So for the business scenario requirements mentioned earlier, how should ShardingSphere be used to achieve business requirements?

New Business

Business scenario analysis: The newly launched business is relatively simple because everything starts from scratch and there is no historical data cleaning problem.
Solution description: After selecting the appropriate encryptor, such as AES, you only need to configure the logical column (write SQL for users) and the ciphertext column (the data table stores the ciphertext data). It can also be different **. The recommended configuration is as follows (shown in Yaml format):
yaml encryptRule: encryptors: aes_encryptor: type: aes props: aes.key.value: 123456abc tables: t_user: columns: pwd: cipherColumn: pwd encryptor: aes_encryptor
With this configuration, Encrypt-JDBC only needs to convert logicColumn and cipherColumn. The underlying data table does not store plain text, only cipher text. This is also a requirement of the security audit part. If users want to store plain text and cipher text together in the database, they just need to add plainColumn configuration. The overall processing flow is shown below:
![5](https://shardingsphere.apache.org/document/current/img/encrypt/5_en.png)

Online Business Transformation

Business scenario analysis: As the business is already running online, there must be a large amount of plain text historical data stored in the database. The current challenges are how to enable historical data to be encrypted and cleaned, how to enable incremental data to be encrypted, and how to allow businesses to seamlessly and transparently migrate between the old and new data systems.
Solution description: Before providing a solution, let ’s brainstorm: First, if the old business needs to be desensitized, it must have stored very important and sensitive information. This information has a high gold content and the business is relatively important. If it is broken, the whole team KPI is over. Therefore, it is impossible to suspend business immediately, prohibit writing of new data, encrypt and clean all historical data with an encrypter, and then deploy the previously reconstructed code online, so that it can encrypt and decrypt online and incremental data. Such a simple and rough way, based on historical experience, will definitely not work.
Then another relatively safe approach is to rebuild a pre-release environment exactly like the production environment, and then encrypt the ** Inventory plaintext data ** of the production environment through the relevant migration and washing tools and store it in the pre-release environment. The ** Increment data ** is encrypted by tools such as MySQL master-slave replication and the business party ’s own development, encrypted and stored in the database of the pre-release environment, and then the refactored code can be deployed to the pre-release environment. In this way, the production environment is a set of environment for ** modified/queries with plain text as the core *; the pre-release environment is a set of * encrypt/decrypt queries modified with ciphertext as the core **. After comparing for a period of time, the production flow can be cut into the pre-release environment at night. This solution is relatively safe and reliable, but it takes more time, manpower, capital, and costs. It mainly includes: pre-release environment construction, production code rectification, and related auxiliary tool development. Unless there is no way to go, business developers generally go from getting started to giving up.
Business developers must hope: reduce the burden of capital costs, do not modify the business code, and be able to safely and smoothly migrate the system. So, the encryption function module of ShardingSphere was born. It can be divided into three steps:
  1. Before system migration
    Assuming that the system needs to encrypt the pwd field of t_user, the business side uses Encrypt-JDBC to replace the standardized JDBC interface, which basically requires no additional modification (we also provide SpringBoot, SpringNameSpace, Yaml and other access methods to achieve different services demand). In addition, demonstrate a set of encryption configuration rules, as follows:
    yaml encryptRule: encryptors: aes_encryptor: type: aes props: aes.key.value: 123456abc tables: t_user: columns: pwd: plainColumn: pwd cipherColumn: pwd_cipher encryptor: aes_encryptor props: query.with.cipher.column: false
    According to the above encryption rules, we need to add a column called pwd_cipher in the t_user table, that is, cipherColumn, which is used to store ciphertext data. At the same time, we set plainColumn to pwd, which is used to store plaintext data, and logicColumn is also set to pwd . Because the previous SQL was written using pwd, that is, the SQL was written for logical columns, so the business code did not need to be changed. Through Encrypt-JDBC, for the incremental data, the plain text will be written to the pwd column, and the plain text will be encrypted and stored in the pwd_cipher column. At this time, because query.with.cipher.column is set to false, for business applications, the plain text column of pwd is still used for query storage, but the cipher text data of the new data is additionally stored on the underlying database table pwd_cipher. The processing flow is shown below:
    ![6](https://shardingsphere.apache.org/document/current/img/encrypt/6_en.png)
    When the newly added data is inserted, it is encrypted as ciphertext data through Encrypt-JDBC and stored in the cipherColumn. Now it is necessary to process historical plaintext inventory data. ** As Apache ShardingSphere currently does not provide the corresponding migration and washing tools, the business party needs to encrypt and store the plain text data in pwd to pwd_cipher. **
  2. During system migration
    The incremental data has been stored by Encrypt-JDBC in the ciphertext column and the plaintext is stored in the plaintext column; after the historical data is encrypted and cleaned by the business party itself, the ciphertext is also stored in the ciphertext column. That is to say, the plaintext and the ciphertext are stored in the current database. Since the query.with.cipher.column = false in the configuration item, the ciphertext has never been used. Now we need to set the query.with.cipher.column in the encryption configuration to true in order for the system to cut the ciphertext data for query. After restarting the system, we found that the system business is normal, but Encrypt-JDBC has started to extract the ciphertext data from the database, decrypt it and return it to the user; and for the user's insert, delete and update requirements, the original data will still be stored The plaintext column, the encrypted ciphertext data is stored in the ciphertext column.
    Although the business system extracts the data in the ciphertext column and returns it after decryption; however, it will still save a copy of the original data to the plaintext column during storage. Why? The answer is: in order to be able to roll back the system. ** Because as long as the ciphertext and plaintext always exist at the same time, we can freely switch the business query to cipherColumn or plainColumn through the configuration of the switch item. ** In other words, if the system is switched to the ciphertext column for query, the system reports an error and needs to be rolled back. Then just set query.with.cipher.column = false, Encrypt-JDBC will restore, that is, start using plainColumn to query again. The processing flow is shown in the following figure:
    ![7](https://shardingsphere.apache.org/document/current/img/encrypt/7_en.png)
  3. After system migration
    Due to the requirements of the security audit department, it is generally impossible for the business system to keep the plaintext and ciphertext columns of the database permanently synchronized. We need to delete the plaintext data after the system is stable. That is, we need to delete plainColumn (ie pwd) after system migration. The problem is that now the business code is written for pwd SQL, delete the pwd in the underlying data table stored in plain text, and use pwd_cipher to decrypt to get the original data, does that mean that the business side needs to rectify all SQL, thus Do not use the pwd column that is about to be deleted? Remember the core meaning of our Encrypt-JDBC?
    This is also the core meaning of Encrypt-JDBC. According to the encryption rules provided by the user, the user SQL is separated from the underlying database table structure, so that the user's SQL writing no longer depends on the actual database table structure. The connection, mapping, and conversion between the user and the underlying database are handled by ShardingSphere.
    Yes, because of the existence of logicColumn, users write SQL for this virtual column. Encrypt-JDBC can map this logical column and the ciphertext column in the underlying data table. So the encryption configuration after migration is:
    yaml encryptRule: encryptors: aes_encryptor: type: aes props: aes.key.value: 123456abc tables: t_user: columns: pwd: # pwd与pwd_cipher的转换映射 cipherColumn: pwd_cipher encryptor: aes_encryptor props: query.with.cipher.column: true
The processing flow is as follows:
![8](https://shardingsphere.apache.org/document/current/img/encrypt/8_en.png)
So far, the online service encryption and rectification solutions have all been demonstrated. We provide Java, Yaml, SpringBoot, SpringNameSpace multiple ways for users to choose to use, and strive to fulfil business requirements. The solution has been continuously launched on JD Digits, providing internal basic service support.

The advantages of Middleware encryption service

  1. Automated & transparent data encryption process, users do not need to pay attention to the implementation details of encryption.
  2. Provide a variety of built-in, third-party (AKS) encryption strategies, users only need to modify the configuration to use.
  3. Provides a encryption strategy API interface, users can implement the interface to use a custom encryption strategy for data encryption.
  4. Support switching different encryption strategies.
  5. For online services, it is possible to store plaintext data and ciphertext data synchronously, and decide whether to use plaintext or ciphertext columns for query through configuration. Without changing the business query SQL, the on-line system can safely and transparently migrate data before and after encryption.

Description of applicable scenarios

  1. User projects are developed in Java.
  2. The back-end databases are MySQL, Oracle, PostgreSQL, and SQLServer.
  3. The user needs to encrypt one or more columns in the database table (data encryption & decryption).
  4. Compatible with all commonly used SQL.

Limitation

  1. Users need to deal with the original inventory data and wash numbers in the database.
  2. Use encryption function + sub-library sub-table function, some special SQL is not supported, please refer to SQL specification
  3. Encryption fields cannot support comparison operations, such as: greater than less than, ORDER BY, BETWEEN, LIKE, etc.
  4. Encryption fields cannot support calculation operations, such as AVG, SUM, and calculation expressions.

Solution

ShardingSphere has provided two data masking solutions, corresponding to two ShardingSphere encryption and decryption interfaces, i.e., ShardingEncryptor and ShardingQueryAssistedEncryptor.
On the one hand, ShardingSphere has provided internal encryption and decryption implementations for users, which can be used by them only after configuration. On the other hand, to satisfy users' requirements for different scenarios, we have also opened relevant encryption and decryption interfaces, according to which, users can provide specific implementation types. Then, after simple configurations, ShardingSphere can use encryption and decryption solutions defined by users themselves to desensitize data.

ShardingEncryptor

The solution has provided two methods encrypt() and decrypt() to encrypt/decrypt data for encryption.
When users INSERT, DELETE and UPDATE, ShardingSphere will parse, rewrite and route SQL according to the configuration. It will also use encrypt() to encrypt data and store them in the database. When using SELECT, they will decrypt sensitive data from the database with decrypt() reversely and return them to users at last.
Currently, ShardingSphere has provided two types of implementations for this kind of masking solution, MD5 (irreversible) and AES (reversible), which can be used after configuration.

ShardingQueryAssistedEncryptor

Compared with the first masking scheme, this one is more secure and complex. Its concept is: even the same data, two same user passwords for example, should not be stored as the same desensitized form in the database. It can help to protect user information and avoid credential stuffing.
This scheme provides three functions to implement, encrypt(), decrypt() and queryAssistedEncrypt(). In encrypt() phase, users can set some variable, timestamp for example, and encrypt a combination of original data + variable. This method can make sure the encrypted masking data of the same original data are different, due to the existence of variables. In decrypt() phase, users can use variable data to decrypt according to the encryption algorithms set formerly.
Though this method can indeed increase data security, another problem can appear with it: as the same data is stored in the database in different content, users may not be able to find out all the same original data with equivalent query (SELECT FROM table WHERE encryptedColumnn = ?) according to this encryption column.Because of it, we have brought out assistant query column, which is generated by queryAssistedEncrypt(). Different from decrypt(), this method uses another way to encrypt the original data; but for the same original data, it can generate consistent encryption data. Users can store data processed by queryAssistedEncrypt() to assist the query of original data. So there may be one more assistant query column in the table.
queryAssistedEncrypt() and encrypt() can generate and store different encryption data; decrypt() is reversible and queryAssistedEncrypt() is irreversible. So when querying the original data, we will parse, rewrite and route SQL automatically. We will also use assistant query column to do WHERE queries and use decrypt() to decrypt encrypt() data and return them to users. All these can not be felt by users.
For now, ShardingSphere has abstracted the concept to be an interface for users to develop rather than providing accurate implementation for this kind of masking solution. ShardingSphere will use the accurate implementation of this solution provided by users to desensitize data.

Continuance

This article describes how to use Encrypt-JDBC, one of the ShardingSphere products, SpringBoot, SpringNameSpace are also could be the access form , etc. This form of access mainly focus to Java homogeneous, and is deployed together with business code In a production environment. For heterogeneous languages, ShardingSphere also provides Encrypt-Proxy client. Encrypt-Proxy is a server-side product that implements the binary protocol of MySQL and PostgreSQL. Users can independently deploy the Encrypt-Proxy service, User can access this virtual database server with encryption through third-party database management tools(e.g. Navicat), JAVA connection pool or the command line, just like access ordinary MySQL and PostgreSQL databases.
The encryption function belongs to distributed governance of Apache ShardingSphere. In fact, the Apache ShardingSphere ecosystem also has other more powerful capabilities, such as data sharding, read-write separation, distributed transactions, and monitoring governance. You can even choose any combination of these functions, such as encryption + data sharding, or data sharding + read-write separation, or monitoring governance + data sharding. In addition to the combination of these functions, ShardingSphere also provides various access forms, such as Sharding-JDBC and Sharding-Proxy for different situations.
submitted by Sharding-Sphere to u/Sharding-Sphere [link] [comments]

Jest encountered an unexpected token while using Typescript, React and SPFx

 describe('Enzyme basics', () => { let reactComponent: ReactWrapper; beforeEach(() => { reactComponent = mount(React.createElement( Crud, { spHttpClient: {}, siteUrl: 'bogus', description: 'bogus' } )); }); afterEach(() => { reactComponent.unmount(); }); it('should root web part element exists', () => { // define the css selector let cssSelector: string = '#iceCreamShop'; // find the element using css selector const element = reactComponent.find(cssSelector); expect(element.length).toBeGreaterThan(0); }); }); 
I am trying to run this test, but for some reason Jest is throwing me an error.

 ● Test suite failed to run Jest encountered an unexpected token This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript. By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules". Here's what you can do: • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config. • If you need a custom transformation specify a "transform" option in your config. • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option. You'll find more details and examples of these config options in the docs: https://jestjs.io/docs/en/configuration.html Details: C:\Users\admin\Desktop\github\crud-simple-test\node_modules\@microsoft\sp-http\lib\index.js:12 export { default as HttpClient } from './httpClient/HttpClient'; ^^^^^^ SyntaxError: Unexpected token export at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1059:14) at Object. (src/webparts/crud/components/Todolist/Todolist.tsx:7025:27) console.log src/webparts/crud/components/Store/reducers.ts:486 action type @@redux/INIT3.m.1.6.8.p is not found 
I've tried various stuffs, but I have no idea how to fix this. This is my package.json. I am using a Typescript React application using SPFx. I think it's an issue with Microsoft library in particular, but maybe it's just some config issue.

This is my jest configuration inside package.json:

 "jest": { "moduleFileExtensions": [ "ts", "tsx", "js" ], "transformIgnorePatterns": [ "/node_modules/" ], "transform": { "^.+\\.(js|ts|tsx)$": "ts-jest" }, "testMatch": [ "**/src/**/*.test.+(ts|tsx|js)" ], "collectCoverage": true, "coverageReporters": [ "json", "lcov", "text", "cobertura" ], "coverageDirectory": "/jest", "moduleNameMapper": { "\\.(css|less|scss|sass)$": "identity-obj-proxy" }, "testResultsProcessor": "jest-junit", "coverageThreshold": { "global": { "branches": 100, "functions": 100, "lines": 100, "statements": 100 } } } 

Now, it seems to be related to the fact that I am using Typescript, but the error doesn't tell me what exactly is the problem and what I should exactly do with my config file. In fact, I think the log is misleading, because the second error points to a js file and not a ts file.
submitted by sharemypenguins to sharepoint [link] [comments]

FlowCards: A Declarative Framework for Development of Ergo dApps

FlowCards: A Declarative Framework for Development of Ergo dApps
Introduction
ErgoScript is the smart contract language used by the Ergo blockchain. While it has concise syntax adopted from Scala/Kotlin, it still may seem confusing at first because conceptually ErgoScript is quite different compared to conventional languages which we all know and love. This is because Ergo is a UTXO based blockchain, whereas smart contracts are traditionally associated with account based systems like Ethereum. However, Ergo's transaction model has many advantages over the account based model and with the right approach it can even be significantly easier to develop Ergo contracts than to write and debug Solidity code.
Below we will cover the key aspects of the Ergo contract model which makes it different:
Paradigm
The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO based programming model on the other hand is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state as result of the contract execution).
Scalability
In the account model of Ethereum both storage changes and validity checks are performed on-chain during code execution. In contrast, Ergo transactions are created off-chain and only validation checks are performed on-chain thus reducing the amount of operations performed by every node on the network. In addition, due to immutability of the transaction graph, various optimization strategies are possible to improve throughput of transactions per second in the network. Light verifying nodes are also possible thus further facilitating scalability and accessibility of the network.
Shared state
The account-based model is reliant on shared mutable state which is known to lead to complex semantics (and subtle million dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with the concurrent and distributed nature of blockchains and facilitates light trustless clients.
Expressive Power
Ethereum advocated execution of a turing-complete language on the blockchain. It theoretically promised unlimited potential, however in practice severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs which limit contract complexity, and other such problems. Ergo on the flip side extends UTXO to enable turing-completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved in a different and more semantically sound way.
With the all of the above points, it should be clear that there are a lot of benefits to the model Ergo is using. In the rest of this article I will introduce you to the concept of FlowCards - a dApp developer component which allows for designing complex Ergo contracts in a declarative and visual way.
From Imperative to Declarative
In the imperative programming model of Ethereum a transaction is a sequence of operations executed by the Ethereum VM. The following Solidity function implements a transfer of tokens from sender to receiver . The transaction starts when sender calls this function on an instance of a contract and ends when the function returns.
// Sends an amount of existing coins from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } 
The function first checks the pre-conditions, then updates the storage (i.e. balances) and finally publishes the post-condition as the Sent event. The gas which is consumed by the transaction is sent to the miner as a reward for executing this transaction.
Unlike Ethereum, a transaction in Ergo is a data structure holding a list of input coins which it spends and a list of output coins which it creates preserving the total balances of ERGs and tokens (in which Ergo is similar to Bitcoin).
Turning back to the example above, since Ergo natively supports tokens, therefore for this specific example of sending tokens we don't need to write any code in ErgoScript. Instead we need to create the ‘send’ transaction shown in the following figure, which describes the same token transfer but declaratively.
https://preview.redd.it/id5kjdgn9tv41.png?width=1348&format=png&auto=webp&s=31b937d7ad0af4afe94f4d023e8c90c97c8aed2e
The picture visually describes the following steps, which the network user needs to perform:
  1. Select unspent sender's boxes, containing in total tB >= amount of tokens and B >= txFee + minErg ERGs.
  2. Create an output target box which is protected by the receiver public key with minErg ERGs and amount of T tokens.
  3. Create one fee output protected by the minerFee contract with txFee ERGs.
  4. Create one change output protected by the sender public key, containing B - minErg - txFee ERGs and tB - amount of T tokens.
  5. Create a new transaction, sign it using the sender's secret key and send to the Ergo network.
What is important to understand here is that all of these steps are preformed off-chain (for example using Appkit Transaction API) by the user's application. Ergo network nodes don't need to repeat this transaction creation process, they only need to validate the already formed transaction. ErgoScript contracts are stored in the inputs of the transaction and check spending conditions. The node executes the contracts on-chain when the transaction is validated. The transaction is valid if all of the conditions are satisfied.
Thus, in Ethereum when we “send amount from sender to recipient” we are literally editing balances and updating the storage with a concrete set of commands. This happens on-chain and thus a new transaction is also created on-chain as the result of this process.
In Ergo (as in Bitcoin) transactions are created off-chain and the network nodes only verify them. The effects of the transaction on the blockchain state is that input coins (or Boxes in Ergo's parlance) are removed and output boxes are added to the UTXO set.
In the example above we don't use an ErgoScript contract but instead assume a signature check is used as the spending pre-condition. However in more complex application scenarios we of course need to use ErgoScript which is what we are going to discuss next.
From Changing State to Checking Context
In the send function example we first checked the pre-condition (require(amount <= balances[msg.sender],...) ) and then changed the state (i.e. update balances balances[msg.sender] -= amount ). This is typical in Ethereum transactions. Before we change anything we need to check if it is valid to do so.
In Ergo, as we discussed previously, the state (i.e. UTXO set of boxes) is changed implicitly when a valid transaction is included in a block. Thus we only need to check the pre-conditions before the transaction can be added to the block. This is what ErgoScript contracts do.
It is not possible to “change the state” in ErgoScript because it is a language to check pre-conditions for spending coins. ErgoScript is a purely functional language without side effects that operates on immutable data values. This means all the inputs, outputs and other transaction parameters available in a script are immutable. This, among other things, makes ErgoScript a very simple language that is easy to learn and safe to use. Similar to Bitcoin, each input box contains a script, which should return the true value in order to 1) allow spending of the box (i.e. removing from the UTXO set) and 2) adding the transaction to the block.
If we are being pedantic, it is therefore incorrect (strictly speaking) to think of ErgoScript as the language of Ergo contracts, because it is the language of propositions (logical predicates, formulas, etc.) which protect boxes from “illegal” spending. Unlike Bitcoin, in Ergo the whole transaction and a part of the current blockchain context is available to every script. Therefore each script may check which outputs are created by the transaction, their ERG and token amounts (we will use this capability in our example DEX contracts), current block number etc.
In ErgoScript you define the conditions of whether changes (i.e. coin spending) are allowed to happen in a given context. This is in contrast to programming the changes imperatively in the code of a contract.
While Ergo's transaction model unlocks a whole range of applications like (DEX, DeFi Apps, LETS, etc), designing contracts as pre-conditions for coin spending (or guarding scripts) directly is not intuitive. In the next sections we will consider a useful graphical notation to design contracts declaratively using FlowCard Diagrams, which is a visual representation of executable components (FlowCards).
FlowCards aim to radically simplify dApp development on the Ergo platform by providing a high-level declarative language, execution runtime, storage format and a graphical notation.
We will start with a high level of diagrams and go down to FlowCard specification.
FlowCard Diagrams
The idea behind FlowCard diagrams is based on the following observations: 1) An Ergo box is immutable and can only be spent in the transaction which uses it as an input. 2) We therefore can draw a flow of boxes through transactions, so that boxes flowing in to the transaction are spent and those flowing out are created and added to the UTXO. 3) A transaction from this perspective is simply a transformer of old boxes to the new ones preserving the balances of ERGs and tokens involved.
The following figure shows the main elements of the Ergo transaction we've already seen previously (now under the name of FlowCard Diagram).
https://preview.redd.it/9kcxl11o9tv41.png?width=1304&format=png&auto=webp&s=378a7f50769292ca94de35ff597dc1a44af56d14
There is a strictly defined meaning (semantics) behind every element of the diagram, so that the diagram is a visual representation (or a view) of the underlying executable component (called FlowCard).
The FlowCard can be used as a reusable component of an Ergo dApp to create and initiate the transaction on the Ergo blockchain. We will discuss this in the coming sections.
Now let's look at the individual pieces of the FlowCard diagram one by one.
  1. Name and Parameters
Each flow card is given a name and a list of typed parameters. This is similar to a template with parameters. In the above figure we can see the Send flow card which has five parameters. The parameters are used in the specification.
  1. Contract Wallet
This is a key element of the flow card. Every box has a guarding script. Often it is the script that checks a signature against a public key. This script is trivial in ErgoScript and is defined like the def pk(pubkey: Address) = { pubkey } template where pubkey is a parameter of the type Address . In the figure, the script template is applied to the parameter pk(sender) and thus a concrete wallet contract is obtained. Therefore pk(sender) and pk(receiver) yield different scripts and represent different wallets on the diagram, even though they use the same template.
Contract Wallet contains a set of all UTXO boxes which have a given script derived from the given script template using flow card parameters. For example, in the figure, the template is pk and parameter pubkey is substituted with the `sender’ flow card parameter.
  1. Contract
Even though a contract is a property of a box, on the diagram we group the boxes by their contracts, therefore it looks like the boxes belong to the contracts, rather than the contracts belong to the boxes. In the example, we have three instantiated contracts pk(sender) , pk(receiver) and minerFee . Note, that pk(sender) is the instantiation of the pk template with the concrete parameter sender and minerFee is the instantiation of the pre-defined contract which protects the miner reward boxes.
  1. Box name
In the diagram we can give each box a name. Besides readability of the diagram, we also use the name as a synonym of a more complex indexed access to the box in the contract. For example, change is the name of the box, which can also be used in the ErgoScript conditions instead of OUTPUTS(2) . We also use box names to associate spending conditions with the boxes.
  1. Boxes in the wallet
In the diagram, we show boxes (darker rectangles) as belonging to the contract wallets (lighter rectangles). Each such box rectangle is connected with a grey transaction rectangle by either orange or green arrows or both. An output box (with an incoming green arrow) may include many lines of text where each line specifies a condition which should be checked as part of the transaction. The first line specifies the condition on the amount of ERG which should be placed in the box. Other lines may take one of the following forms:
  1. amount: TOKEN - the box should contain the given amount of the given TOKEN
  2. R == value - the box should contain the given value of the given register R
  3. boxName ? condition - the box named boxName should check condition in its script.
We discuss these conditions in the sections below.
  1. Amount of ERGs in the box
Each box should store a minimum amount of ERGs. This is checked when the creating transaction is validated. In the diagram the amount of ERGs is always shown as the first line (e.g. B: ERG or B - minErg - txFee ). The value type ascription B: ERG is optional and may be used for readability. When the value is given as a formula, then this formula should be respected by the transaction which creates the box.
It is important to understand that variables like amount and txFee are not named properties of the boxes. They are parameters of the whole diagram and representing some amounts. Or put it another way, they are shared parameters between transactions (e.g. Sell Order and Swap transactions from DEX example below share the tAmt parameter). So the same name is tied to the same value throughout the diagram (this is where the tooling would help a lot). However, when it comes to on-chain validation of those values, only explicit conditions which are marked with ? are transformed to ErgoScript. At the same time, all other conditions are ensured off-chain during transaction building (for example in an application using Appkit API) and transaction validation when it is added to the blockchain.
  1. Amount of T token
A box can store values of many tokens. The tokens on the diagram are named and a value variable may be associated with the token T using value: T expression. The value may be given by formula. If the formula is prefixed with a box name like boxName ? formula , then it is should also be checked in the guarding script of the boxName box. This additional specification is very convenient because 1) it allows to validate the visual design automatically, and 2) the conditions specified in the boxes of a diagram are enough to synthesize the necessary guarding scripts. (more about this below at “From Diagrams To ErgoScript Contracts”)
  1. Tx Inputs
Inputs are connected to the corresponding transaction by orange arrows. An input arrow may have a label of the following forms:
  1. [email protected] - optional name with an index i.e. [email protected] or u/2 . This is a property of the target endpoint of the arrow. The name is used in conditions of related boxes and the index is the position of the corresponding box in the INPUTS collection of the transaction.
  2. !action - is a property of the source of the arrow and gives a name for an alternative spending path of the box (we will see this in DEX example)
Because of alternative spending paths, a box may have many outgoing orange arrows, in which case they should be labeled with different actions.
  1. Transaction
A transaction spends input boxes and creates output boxes. The input boxes are given by the orange arrows and the labels are expected to put inputs at the right indexes in INPUTS collection. The output boxes are given by the green arrows. Each transaction should preserve a strict balance of ERG values (sum of inputs == sum of outputs) and for each token the sum of inputs >= the sum of outputs. The design diagram requires an explicit specification of the ERG and token values for all of the output boxes to avoid implicit errors and ensure better readability.
  1. Tx Outputs
Outputs are connected to the corresponding transaction by green arrows. An output arrow may have a label of the following [email protected] , where an optional name is accompanied with an index i.e. [email protected] or u/2 . This is a property of the source endpoint of the arrow. The name is used in conditions of the related boxes and the index is the position of the corresponding box in the OUTPUTS collection of the transaction.
Example: Decentralized Exchange (DEX)
Now let's use the above described notation to design a FlowCard for a DEX dApp. It is simple enough yet also illustrates all of the key features of FlowCard diagrams which we've introduced in the previous section.
The dApp scenario is shown in the figure below: There are three participants (buyer, seller and DEX) of the DEX dApp and five different transaction types, which are created by participants. The buyer wants to swap ergAmt of ERGs for tAmt of TID tokens (or vice versa, the seller wants to sell TID tokens for ERGs, who sends the order first doesn't matter). Both the buyer and the seller can cancel their orders any time. The DEX off-chain matching service can find matching orders and create the Swap transaction to complete the exchange.
The following diagram fully (and formally) specifies all of the five transactions that must be created off-chain by the DEX dApp. It also specifies all of the spending conditions that should be verified on-chain.

https://preview.redd.it/fnt5f4qp9tv41.png?width=1614&format=png&auto=webp&s=34f145f9a6d622454906857e645def2faba057bd
Let's discuss the FlowCard diagram and the logic of each transaction in details:
Buy Order Transaction
A buyer creates a Buy Order transaction. The transaction spends E amount of ERGs (which we will write E: ERG ) from one or more boxes in the pk(buyer) wallet. The transaction creates a bid box with ergAmt: ERG protected by the buyOrder script. The buyOrder script is synthesized from the specification (see below at “From Diagrams To ErgoScript Contracts”) either manually or automatically by a tool. Even though we don't need to define the buyOrder script explicitly during designing, at run time the bid box should contain the buyOrder script as the guarding proposition (which checks the box spending conditions), otherwise the conditions specified in the diagram will not be checked.
The change box is created to make the input and output sums of the transaction balanced. The transaction fee box is omitted because it can be added automatically by the tools. In practice, however, the designer can add the fee box explicitly to the a diagram. It covers the cases of more complex transactions (like Swap) where there are many ways to pay the transaction fee.
Cancel Buy, Cancel Sell Transactions
At any time, the buyer can cancel the order by sending CancelBuy transaction. The transaction should satisfy the guarding buyOrder contract which protects the bid box. As you can see on the diagram, both the Cancel and the Swap transactions can spend the bid box. When a box has spending alternatives (or spending paths) then each alternative is identified by a unique name prefixed with ! (!cancel and !swap for the bid box). Each alternative path has specific spending conditions. In our example, when the Cancel Buy transaction spends the bid box the ?buyer condition should be satisfied, which we read as “the signature for the buyer address should be presented in the transaction”. Therefore, only buyer can cancel the buy order. This “signature” condition is only required for the !cancel alternative spending path and not required for !swap .
Sell Order Transaction
The Sell Order transaction is similar to the BuyOrder in that it deals with tokens in addition to ERGs. The transaction spends E: ERG and T: TID tokens from seller's wallet (specified as pk(seller) contract). The two outputs are ask and change . The change is a standard box to balance transaction. The ask box keeps tAmt: TID tokens for the exchange and minErg: ERG - the minimum amount of ERGs required in every box.
Swap Transaction
This is a key transaction in the DEX dApp scenario. The transaction has several spending conditions on the input boxes and those conditions are included in the buyOrder and sellOrder scripts (which are verified when the transaction is added to the blockchain). However, on the diagram those conditions are not specified in the bid and ask boxes, they are instead defined in the output boxes of the transaction.
This is a convention for improved usability because most of the conditions relate to the properties of the output boxes. We could specify those properties in the bid box, but then we would have to use more complex expressions.
Let's consider the output created by the arrow labeled with [email protected] . This label tells us that the output is at the index 0 in the OUTPUTS collection of the transaction and that in the diagram we can refer to this box by the buyerOut name. Thus we can label both the box itself and the arrow to give the box a name.
The conditions shown in the buyerOut box have the form bid ? condition , which means they should be verified on-chain in order to spend the bid box. The conditions have the following meaning:
  • tAmt: TID requires the box to have tAmt amount of TID token
  • R4 == bid.id requires R4 register in the box to be equal to id of the bid box.
  • script == buyer requires the buyerOut box to have the script of the wallet where it is located on the diagram, i.e. pk(buyer)
Similar properties are added to the sellerOut box, which is specified to be at index 1 and the name is given to it using the label on the box itself, rather than on the arrow.
The Swap transaction spends two boxes bid and ask using the !swap spending path on both, however unlike !cancel the conditions on the path are not specified. This is where the bid ? and ask ? prefixes come into play. They are used so that the conditions listed in the buyerOut and sellerOut boxes are moved to the !swap spending path of the bid and ask boxes correspondingly.
If you look at the conditions of the output boxes, you will see that they exactly specify the swap of values between seller's and buyer's wallets. The buyer gets the necessary amount of TID token and seller gets the corresponding amount of ERGs. The Swap transaction is created when there are two matching boxes with buyOrder and sellOrder contracts.
From Diagrams To ErgoScript Contracts
What is interesting about FlowCard specifications is that we can use them to automatically generate the necessary ErgoTree scripts. With the appropriate tooling support this can be done automatically, but with the lack of thereof, it can be done manually. Thus, the FlowCard allows us to capture and visually represent all of the design choices and semantic details of an Ergo dApp.
What we are going to do next is to mechanically create the buyOrder contract from the information given in the DEX flow card.
Recall that each script is a proposition (boolean valued expression) which should evaluate to true to allow spending of the box. When we have many conditions to be met at the same time we can combine them in a logical formula using the AND binary operation, and if we have alternatives (not necessarily exclusive) we can put them into the OR operation.
The buyOrder box has the alternative spending paths !cancel and !swap . Thus the ErgoScript code should have OR operation with two arguments - one for each spending path.
/** buyOrder contract */ { val cancelCondition = {} val swapCondition = {} cancelCondition || swapCondition } 
The formula for the cancelCondition expression is given in the !cancel spending path of the buyOrder box. We can directly include it in the script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = {} cancelCondition || swapCondition } 
For the !swap spending path of the buyOrder box the conditions are specified in the buyerOut output box of the Swap transaction. If we simply include them in the swapCondition then we get a syntactically incorrect script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = { tAmt: TID && R4 == bid.id && @contract } cancelCondition || swapCondition } 
We can however translate the conditions from the diagram syntax to ErgoScript expressions using the following simple rules
  1. [email protected] ==> val buyerOut = OUTPUTS(0)
  2. tAmt: TID ==> tid._2 == tAmt where tid = buyerOut.tokens(TID)
  3. R4 == bid.id ==> R4 == SELF.id where R4 = buyerOut.R4[Coll[Byte]].get
  4. script == buyer ==> buyerOut.propositionBytes == buyer.propBytes
Note, in the diagram TID represents a token id, but ErgoScript doesn't have access to the tokens by the ids so we cannot write tokens.getByKey(TID) . For this reason, when the diagram is translated into ErgoScript, TID becomes a named constant of the index in tokens collection of the box. The concrete value of the constant is assigned when the BuyOrder transaction with the buyOrder box is created. The correspondence and consistency between the actual tokenId, the TID constant and the actual tokens of the buyerOut box is ensured by the off-chain application code, which is completely possible since all of the transactions are created by the application using FlowCard as a guiding specification. This may sound too complicated, but this is part of the translation from diagram specification to actual executable application code, most of which can be automated.
After the transformation we can obtain a correct script which checks all the required preconditions for spending the buyOrder box.
/** buyOrder contract */ def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long) { val cancelCondition: SigmaProp = { buyer } // verify buyer's sig (ProveDlog) val swapCondition = OUTPUTS.size > 0 && { // securing OUTPUTS access val buyerOut = OUTPUTS(0) // from [email protected] buyerOut.tokens.size > TID && { // securing tokens access val tid = buyerOut.tokens(TID) val regR4 = buyerOut.R4[Coll[Byte]] regR4.isDefined && { // securing R4 access val R4 = regR4.get tid._2 == tAmt && // from tAmt: TID R4 == SELF.id && // from R4 == bid.id buyerOut.propositionBytes == buyer.propBytes // from script == buyer } } } cancelCondition || swapCondition } 
A similar script for the sellOrder box can be obtained using the same translation rules. With the help of the tooling the code of contracts can be mechanically generated from the diagram specification.
Conclusions
Declarative programming models have already won the battle against imperative programming in many application domains like Big Data, Stream Processing, Deep Learning, Databases, etc. Ergo is pioneering the declarative model of dApp development as a better and safer alternative to the now popular imperative model of smart contracts.
The concept of FlowCard shifts the focus from writing ErgoScript contracts to the overall flow of values (hence the name), in such a way, that ErgoScript can always be generated from them. You will never need to look at the ErgoScript code once the tooling is in place.
Here are the possible next steps for future work:
  1. Storage format for FlowCard Spec and the corresponding EIP standardized file format (Json/XML/Protobuf). This will allow various tools (Diagram Editor, Runtime, dApps etc) to create and use *.flowcard files.
  2. FlowCard Viewer, which can generate the diagrams from *.flowcard files.
  3. FlowCard Runtime, which can run *.flowcard files, create and send transactions to Ergo network.
  4. FlowCard Designer Tool, which can simplify development of complex diagrams . This will make designing and validation of Ergo contracts a pleasant experience, more like drawing rather than coding. In addition, the correctness of the whole dApp scenario can be verified and controlled by the tooling.
submitted by Guilty_Pea to CryptoCurrencies [link] [comments]

FlowCards: A Declarative Framework for Development of Ergo dApps

FlowCards: A Declarative Framework for Development of Ergo dApps
Introduction
ErgoScript is the smart contract language used by the Ergo blockchain. While it has concise syntax adopted from Scala/Kotlin, it still may seem confusing at first because conceptually ErgoScript is quite different compared to conventional languages which we all know and love. This is because Ergo is a UTXO based blockchain, whereas smart contracts are traditionally associated with account based systems like Ethereum. However, Ergo's transaction model has many advantages over the account based model and with the right approach it can even be significantly easier to develop Ergo contracts than to write and debug Solidity code.
Below we will cover the key aspects of the Ergo contract model which makes it different:
Paradigm
The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO based programming model on the other hand is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state as result of the contract execution).
Scalability
In the account model of Ethereum both storage changes and validity checks are performed on-chain during code execution. In contrast, Ergo transactions are created off-chain and only validation checks are performed on-chain thus reducing the amount of operations performed by every node on the network. In addition, due to immutability of the transaction graph, various optimization strategies are possible to improve throughput of transactions per second in the network. Light verifying nodes are also possible thus further facilitating scalability and accessibility of the network.
Shared state
The account-based model is reliant on shared mutable state which is known to lead to complex semantics (and subtle million dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with the concurrent and distributed nature of blockchains and facilitates light trustless clients.
Expressive Power
Ethereum advocated execution of a turing-complete language on the blockchain. It theoretically promised unlimited potential, however in practice severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs which limit contract complexity, and other such problems. Ergo on the flip side extends UTXO to enable turing-completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved in a different and more semantically sound way.
With the all of the above points, it should be clear that there are a lot of benefits to the model Ergo is using. In the rest of this article I will introduce you to the concept of FlowCards - a dApp developer component which allows for designing complex Ergo contracts in a declarative and visual way.

From Imperative to Declarative

In the imperative programming model of Ethereum a transaction is a sequence of operations executed by the Ethereum VM. The following Solidity function implements a transfer of tokens from sender to receiver . The transaction starts when sender calls this function on an instance of a contract and ends when the function returns.
// Sends an amount of existing coins from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } 
The function first checks the pre-conditions, then updates the storage (i.e. balances) and finally publishes the post-condition as the Sent event. The gas which is consumed by the transaction is sent to the miner as a reward for executing this transaction.
Unlike Ethereum, a transaction in Ergo is a data structure holding a list of input coins which it spends and a list of output coins which it creates preserving the total balances of ERGs and tokens (in which Ergo is similar to Bitcoin).
Turning back to the example above, since Ergo natively supports tokens, therefore for this specific example of sending tokens we don't need to write any code in ErgoScript. Instead we need to create the ‘send’ transaction shown in the following figure, which describes the same token transfer but declaratively.
https://preview.redd.it/sxs3kesvrsv41.png?width=1348&format=png&auto=webp&s=582382bc26912ff79114d831d937d94b6988e69f
The picture visually describes the following steps, which the network user needs to perform:
  1. Select unspent sender's boxes, containing in total tB >= amount of tokens and B >= txFee + minErg ERGs.
  2. Create an output target box which is protected by the receiver public key with minErg ERGs and amount of T tokens.
  3. Create one fee output protected by the minerFee contract with txFee ERGs.
  4. Create one change output protected by the sender public key, containing B - minErg - txFee ERGs and tB - amount of T tokens.
  5. Create a new transaction, sign it using the sender's secret key and send to the Ergo network.
What is important to understand here is that all of these steps are preformed off-chain (for example using Appkit Transaction API) by the user's application. Ergo network nodes don't need to repeat this transaction creation process, they only need to validate the already formed transaction. ErgoScript contracts are stored in the inputs of the transaction and check spending conditions. The node executes the contracts on-chain when the transaction is validated. The transaction is valid if all of the conditions are satisfied.
Thus, in Ethereum when we “send amount from sender to recipient” we are literally editing balances and updating the storage with a concrete set of commands. This happens on-chain and thus a new transaction is also created on-chain as the result of this process.
In Ergo (as in Bitcoin) transactions are created off-chain and the network nodes only verify them. The effects of the transaction on the blockchain state is that input coins (or Boxes in Ergo's parlance) are removed and output boxes are added to the UTXO set.
In the example above we don't use an ErgoScript contract but instead assume a signature check is used as the spending pre-condition. However in more complex application scenarios we of course need to use ErgoScript which is what we are going to discuss next.

From Changing State to Checking Context

In the send function example we first checked the pre-condition (require(amount <= balances[msg.sender],...) ) and then changed the state (i.e. update balances balances[msg.sender] -= amount ). This is typical in Ethereum transactions. Before we change anything we need to check if it is valid to do so.
In Ergo, as we discussed previously, the state (i.e. UTXO set of boxes) is changed implicitly when a valid transaction is included in a block. Thus we only need to check the pre-conditions before the transaction can be added to the block. This is what ErgoScript contracts do.
It is not possible to “change the state” in ErgoScript because it is a language to check pre-conditions for spending coins. ErgoScript is a purely functional language without side effects that operates on immutable data values. This means all the inputs, outputs and other transaction parameters available in a script are immutable. This, among other things, makes ErgoScript a very simple language that is easy to learn and safe to use. Similar to Bitcoin, each input box contains a script, which should return the true value in order to 1) allow spending of the box (i.e. removing from the UTXO set) and 2) adding the transaction to the block.
If we are being pedantic, it is therefore incorrect (strictly speaking) to think of ErgoScript as the language of Ergo contracts, because it is the language of propositions (logical predicates, formulas, etc.) which protect boxes from “illegal” spending. Unlike Bitcoin, in Ergo the whole transaction and a part of the current blockchain context is available to every script. Therefore each script may check which outputs are created by the transaction, their ERG and token amounts (we will use this capability in our example DEX contracts), current block number etc.
In ErgoScript you define the conditions of whether changes (i.e. coin spending) are allowed to happen in a given context. This is in contrast to programming the changes imperatively in the code of a contract.
While Ergo's transaction model unlocks a whole range of applications like (DEX, DeFi Apps, LETS, etc), designing contracts as pre-conditions for coin spending (or guarding scripts) directly is not intuitive. In the next sections we will consider a useful graphical notation to design contracts declaratively using FlowCard Diagrams, which is a visual representation of executable components (FlowCards).
FlowCards aim to radically simplify dApp development on the Ergo platform by providing a high-level declarative language, execution runtime, storage format and a graphical notation.
We will start with a high level of diagrams and go down to FlowCard specification.

FlowCard Diagrams

The idea behind FlowCard diagrams is based on the following observations: 1) An Ergo box is immutable and can only be spent in the transaction which uses it as an input. 2) We therefore can draw a flow of boxes through transactions, so that boxes flowing in to the transaction are spent and those flowing out are created and added to the UTXO. 3) A transaction from this perspective is simply a transformer of old boxes to the new ones preserving the balances of ERGs and tokens involved.
The following figure shows the main elements of the Ergo transaction we've already seen previously (now under the name of FlowCard Diagram).
https://preview.redd.it/06aqkcd1ssv41.png?width=1304&format=png&auto=webp&s=106eda730e0526919aabd5af9596b97e45b69777
There is a strictly defined meaning (semantics) behind every element of the diagram, so that the diagram is a visual representation (or a view) of the underlying executable component (called FlowCard).
The FlowCard can be used as a reusable component of an Ergo dApp to create and initiate the transaction on the Ergo blockchain. We will discuss this in the coming sections.
Now let's look at the individual pieces of the FlowCard diagram one by one.
1. Name and Parameters
Each flow card is given a name and a list of typed parameters. This is similar to a template with parameters. In the above figure we can see the Send flow card which has five parameters. The parameters are used in the specification.
2. Contract Wallet
This is a key element of the flow card. Every box has a guarding script. Often it is the script that checks a signature against a public key. This script is trivial in ErgoScript and is defined like the def pk(pubkey: Address) = { pubkey } template where pubkey is a parameter of the type Address . In the figure, the script template is applied to the parameter pk(sender) and thus a concrete wallet contract is obtained. Therefore pk(sender) and pk(receiver) yield different scripts and represent different wallets on the diagram, even though they use the same template.
Contract Wallet contains a set of all UTXO boxes which have a given script derived from the given script template using flow card parameters. For example, in the figure, the template is pk and parameter pubkey is substituted with the `sender’ flow card parameter.
3. Contract
Even though a contract is a property of a box, on the diagram we group the boxes by their contracts, therefore it looks like the boxes belong to the contracts, rather than the contracts belong to the boxes. In the example, we have three instantiated contracts pk(sender) , pk(receiver) and minerFee . Note, that pk(sender) is the instantiation of the pk template with the concrete parameter sender and minerFee is the instantiation of the pre-defined contract which protects the miner reward boxes.
4. Box name
In the diagram we can give each box a name. Besides readability of the diagram, we also use the name as a synonym of a more complex indexed access to the box in the contract. For example, change is the name of the box, which can also be used in the ErgoScript conditions instead of OUTPUTS(2) . We also use box names to associate spending conditions with the boxes.
5. Boxes in the wallet
In the diagram, we show boxes (darker rectangles) as belonging to the contract wallets (lighter rectangles). Each such box rectangle is connected with a grey transaction rectangle by either orange or green arrows or both. An output box (with an incoming green arrow) may include many lines of text where each line specifies a condition which should be checked as part of the transaction. The first line specifies the condition on the amount of ERG which should be placed in the box. Other lines may take one of the following forms:
  1. amount: TOKEN - the box should contain the given amount of the given TOKEN
  2. R == value - the box should contain the given value of the given register R
  3. boxName ? condition - the box named boxName should check condition in its script.
We discuss these conditions in the sections below.
6. Amount of ERGs in the box
Each box should store a minimum amount of ERGs. This is checked when the creating transaction is validated. In the diagram the amount of ERGs is always shown as the first line (e.g. B: ERG or B - minErg - txFee ). The value type ascription B: ERG is optional and may be used for readability. When the value is given as a formula, then this formula should be respected by the transaction which creates the box.
It is important to understand that variables like amount and txFee are not named properties of the boxes. They are parameters of the whole diagram and representing some amounts. Or put it another way, they are shared parameters between transactions (e.g. Sell Order and Swap transactions from DEX example below share the tAmt parameter). So the same name is tied to the same value throughout the diagram (this is where the tooling would help a lot). However, when it comes to on-chain validation of those values, only explicit conditions which are marked with ? are transformed to ErgoScript. At the same time, all other conditions are ensured off-chain during transaction building (for example in an application using Appkit API) and transaction validation when it is added to the blockchain.
7. Amount of T token
A box can store values of many tokens. The tokens on the diagram are named and a value variable may be associated with the token T using value: T expression. The value may be given by formula. If the formula is prefixed with a box name like boxName ? formula , then it is should also be checked in the guarding script of the boxName box. This additional specification is very convenient because 1) it allows to validate the visual design automatically, and 2) the conditions specified in the boxes of a diagram are enough to synthesize the necessary guarding scripts. (more about this below at “From Diagrams To ErgoScript Contracts”)
8. Tx Inputs
Inputs are connected to the corresponding transaction by orange arrows. An input arrow may have a label of the following forms:
  1. [email protected] - optional name with an index i.e. [email protected] or u/2 . This is a property of the target endpoint of the arrow. The name is used in conditions of related boxes and the index is the position of the corresponding box in the INPUTS collection of the transaction.
  2. !action - is a property of the source of the arrow and gives a name for an alternative spending path of the box (we will see this in DEX example)
Because of alternative spending paths, a box may have many outgoing orange arrows, in which case they should be labeled with different actions.
9. Transaction
A transaction spends input boxes and creates output boxes. The input boxes are given by the orange arrows and the labels are expected to put inputs at the right indexes in INPUTS collection. The output boxes are given by the green arrows. Each transaction should preserve a strict balance of ERG values (sum of inputs == sum of outputs) and for each token the sum of inputs >= the sum of outputs. The design diagram requires an explicit specification of the ERG and token values for all of the output boxes to avoid implicit errors and ensure better readability.
10. Tx Outputs
Outputs are connected to the corresponding transaction by green arrows. An output arrow may have a label of the following [email protected] , where an optional name is accompanied with an index i.e. [email protected] or u/2 . This is a property of the source endpoint of the arrow. The name is used in conditions of the related boxes and the index is the position of the corresponding box in the OUTPUTS collection of the transaction.

Example: Decentralized Exchange (DEX)

Now let's use the above described notation to design a FlowCard for a DEX dApp. It is simple enough yet also illustrates all of the key features of FlowCard diagrams which we've introduced in the previous section.
The dApp scenario is shown in the figure below: There are three participants (buyer, seller and DEX) of the DEX dApp and five different transaction types, which are created by participants. The buyer wants to swap ergAmt of ERGs for tAmt of TID tokens (or vice versa, the seller wants to sell TID tokens for ERGs, who sends the order first doesn't matter). Both the buyer and the seller can cancel their orders any time. The DEX off-chain matching service can find matching orders and create the Swap transaction to complete the exchange.
The following diagram fully (and formally) specifies all of the five transactions that must be created off-chain by the DEX dApp. It also specifies all of the spending conditions that should be verified on-chain.

https://preview.redd.it/piogz0v9ssv41.png?width=1614&format=png&auto=webp&s=e1b503a635ad3d138ef91e2f0c3b726e78958646
Let's discuss the FlowCard diagram and the logic of each transaction in details:
Buy Order Transaction
A buyer creates a Buy Order transaction. The transaction spends E amount of ERGs (which we will write E: ERG ) from one or more boxes in the pk(buyer) wallet. The transaction creates a bid box with ergAmt: ERG protected by the buyOrder script. The buyOrder script is synthesized from the specification (see below at “From Diagrams To ErgoScript Contracts”) either manually or automatically by a tool. Even though we don't need to define the buyOrder script explicitly during designing, at run time the bid box should contain the buyOrder script as the guarding proposition (which checks the box spending conditions), otherwise the conditions specified in the diagram will not be checked.
The change box is created to make the input and output sums of the transaction balanced. The transaction fee box is omitted because it can be added automatically by the tools. In practice, however, the designer can add the fee box explicitly to the a diagram. It covers the cases of more complex transactions (like Swap) where there are many ways to pay the transaction fee.
Cancel Buy, Cancel Sell Transactions
At any time, the buyer can cancel the order by sending CancelBuy transaction. The transaction should satisfy the guarding buyOrder contract which protects the bid box. As you can see on the diagram, both the Cancel and the Swap transactions can spend the bid box. When a box has spending alternatives (or spending paths) then each alternative is identified by a unique name prefixed with ! (!cancel and !swap for the bid box). Each alternative path has specific spending conditions. In our example, when the Cancel Buy transaction spends the bid box the ?buyer condition should be satisfied, which we read as “the signature for the buyer address should be presented in the transaction”. Therefore, only buyer can cancel the buy order. This “signature” condition is only required for the !cancel alternative spending path and not required for !swap .
Sell Order Transaction
The Sell Order transaction is similar to the BuyOrder in that it deals with tokens in addition to ERGs. The transaction spends E: ERG and T: TID tokens from seller's wallet (specified as pk(seller) contract). The two outputs are ask and change . The change is a standard box to balance transaction. The ask box keeps tAmt: TID tokens for the exchange and minErg: ERG - the minimum amount of ERGs required in every box.
Swap Transaction
This is a key transaction in the DEX dApp scenario. The transaction has several spending conditions on the input boxes and those conditions are included in the buyOrder and sellOrder scripts (which are verified when the transaction is added to the blockchain). However, on the diagram those conditions are not specified in the bid and ask boxes, they are instead defined in the output boxes of the transaction.
This is a convention for improved usability because most of the conditions relate to the properties of the output boxes. We could specify those properties in the bid box, but then we would have to use more complex expressions.
Let's consider the output created by the arrow labeled with [email protected] . This label tells us that the output is at the index 0 in the OUTPUTS collection of the transaction and that in the diagram we can refer to this box by the buyerOut name. Thus we can label both the box itself and the arrow to give the box a name.
The conditions shown in the buyerOut box have the form bid ? condition , which means they should be verified on-chain in order to spend the bid box. The conditions have the following meaning:
  • tAmt: TID requires the box to have tAmt amount of TID token
  • R4 == bid.id requires R4 register in the box to be equal to id of the bid box.
  • script == buyer requires the buyerOut box to have the script of the wallet where it is located on the diagram, i.e. pk(buyer)
Similar properties are added to the sellerOut box, which is specified to be at index 1 and the name is given to it using the label on the box itself, rather than on the arrow.
The Swap transaction spends two boxes bid and ask using the !swap spending path on both, however unlike !cancel the conditions on the path are not specified. This is where the bid ? and ask ? prefixes come into play. They are used so that the conditions listed in the buyerOut and sellerOut boxes are moved to the !swap spending path of the bid and ask boxes correspondingly.
If you look at the conditions of the output boxes, you will see that they exactly specify the swap of values between seller's and buyer's wallets. The buyer gets the necessary amount of TID token and seller gets the corresponding amount of ERGs. The Swap transaction is created when there are two matching boxes with buyOrder and sellOrder contracts.

From Diagrams To ErgoScript Contracts

What is interesting about FlowCard specifications is that we can use them to automatically generate the necessary ErgoTree scripts. With the appropriate tooling support this can be done automatically, but with the lack of thereof, it can be done manually. Thus, the FlowCard allows us to capture and visually represent all of the design choices and semantic details of an Ergo dApp.
What we are going to do next is to mechanically create the buyOrder contract from the information given in the DEX flow card.
Recall that each script is a proposition (boolean valued expression) which should evaluate to true to allow spending of the box. When we have many conditions to be met at the same time we can combine them in a logical formula using the AND binary operation, and if we have alternatives (not necessarily exclusive) we can put them into the OR operation.
The buyOrder box has the alternative spending paths !cancel and !swap . Thus the ErgoScript code should have OR operation with two arguments - one for each spending path.
/** buyOrder contract */ { val cancelCondition = {} val swapCondition = {} cancelCondition || swapCondition } 
The formula for the cancelCondition expression is given in the !cancel spending path of the buyOrder box. We can directly include it in the script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = {} cancelCondition || swapCondition } 
For the !swap spending path of the buyOrder box the conditions are specified in the buyerOut output box of the Swap transaction. If we simply include them in the swapCondition then we get a syntactically incorrect script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = { tAmt: TID && R4 == bid.id && @contract } cancelCondition || swapCondition } 
We can however translate the conditions from the diagram syntax to ErgoScript expressions using the following simple rules
  1. [email protected] ==> val buyerOut = OUTPUTS(0)
  2. tAmt: TID ==> tid._2 == tAmt where tid = buyerOut.tokens(TID)
  3. R4 == bid.id ==> R4 == SELF.id where R4 = buyerOut.R4[Coll[Byte]].get
  4. script == buyer ==> buyerOut.propositionBytes == buyer.propBytes
Note, in the diagram TID represents a token id, but ErgoScript doesn't have access to the tokens by the ids so we cannot write tokens.getByKey(TID) . For this reason, when the diagram is translated into ErgoScript, TID becomes a named constant of the index in tokens collection of the box. The concrete value of the constant is assigned when the BuyOrder transaction with the buyOrder box is created. The correspondence and consistency between the actual tokenId, the TID constant and the actual tokens of the buyerOut box is ensured by the off-chain application code, which is completely possible since all of the transactions are created by the application using FlowCard as a guiding specification. This may sound too complicated, but this is part of the translation from diagram specification to actual executable application code, most of which can be automated.
After the transformation we can obtain a correct script which checks all the required preconditions for spending the buyOrder box.
/** buyOrder contract */ def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long) { val cancelCondition: SigmaProp = { buyer } // verify buyer's sig (ProveDlog) val swapCondition = OUTPUTS.size > 0 && { // securing OUTPUTS access val buyerOut = OUTPUTS(0) // from [email protected] buyerOut.tokens.size > TID && { // securing tokens access val tid = buyerOut.tokens(TID) val regR4 = buyerOut.R4[Coll[Byte]] regR4.isDefined && { // securing R4 access val R4 = regR4.get tid._2 == tAmt && // from tAmt: TID R4 == SELF.id && // from R4 == bid.id buyerOut.propositionBytes == buyer.propBytes // from script == buyer } } } cancelCondition || swapCondition } 
A similar script for the sellOrder box can be obtained using the same translation rules. With the help of the tooling the code of contracts can be mechanically generated from the diagram specification.

Conclusions

Declarative programming models have already won the battle against imperative programming in many application domains like Big Data, Stream Processing, Deep Learning, Databases, etc. Ergo is pioneering the declarative model of dApp development as a better and safer alternative to the now popular imperative model of smart contracts.
The concept of FlowCard shifts the focus from writing ErgoScript contracts to the overall flow of values (hence the name), in such a way, that ErgoScript can always be generated from them. You will never need to look at the ErgoScript code once the tooling is in place.
Here are the possible next steps for future work:
  1. Storage format for FlowCard Spec and the corresponding EIP standardized file format (Json/XML/Protobuf). This will allow various tools (Diagram Editor, Runtime, dApps etc) to create and use *.flowcard files.
  2. FlowCard Viewer, which can generate the diagrams from *.flowcard files.
  3. FlowCard Runtime, which can run *.flowcard files, create and send transactions to Ergo network.
  4. FlowCard Designer Tool, which can simplify development of complex diagrams . This will make designing and validation of Ergo contracts a pleasant experience, more like drawing rather than coding. In addition, the correctness of the whole dApp scenario can be verified and controlled by the tooling.
submitted by eleanorcwhite to btc [link] [comments]

The middle ground - The bull getting stung by the bee.

Welcome to the sixth installment of the middleground, where we can discuss issues in the show that are the most, "burning" or "controversial" with two sides that are not too willing to accept each other. I hope for this to be a productive discussion and for it all sides to come to the table and discuss. You can find the previous installment here
https://www.reddit.com/RWBY/comments/bb6mko/the\_middle\_ground\_ozzy\_the\_prince\_of\_darkess/
Its been a long time since i have done this (Bloody exams) But here we go. As the title implies, this time i want to discuss and portray the arguments (And to agree/disagree) that are flying over the fight at the end of Volume 6 with Adam versus Yang/Blake. It was divisive to say the least, the fight created or widened the fracture between the two parts of the community and even made some people drop the show outright. I myself, well, found myself in the middle. I liked the fight, but I could not agree with many others who did outright because of the reasons I will outline below.

The Clash

Well, I do not think I need to explain this one. The ending of V6 was, divisive to say the least, I find it strange that it was so, but maybe that was to be expected after V5 and the forming of a group of people that I can only refer to as a “hatedom”. To many it was a return to form, a volume showing that CRWBY have learned from their past mistakes and are now improving based on feedback, to others, it was a volume that convinced them that the show was not going to get better or that it gets worse based on some of more questionable? Writing decisions in the latter part of the volume.
One of the biggest point of contention is the fight of Adam versus the Bee and the Cat, aka, Yang and Blake. It seems to be the main moment that broke or made the volume for some people, and there are many clash points over this fight that I am going to attempt to cover here. Be aware, that this generalizes some of the opinions and might not apply to everyone, moreover, this is an opinion.

The middle ground

Shipping

So let us start with this bombshell of an argument. One side claims that Adam was killed just for shipping, that he, as a character was sacrificed on the altar of the bees. I have to begin by disagreeing with this statement entirely. Let us be honest here, the WF and the racism angle of RWBY has not been handled well at all, most people that watched RWBY can acknowledge that and point to many better examples of this kind of thing being done. And over Volume 5 we have seen the resolution of at least the White Fang plot, the writers simply want to get rid of it, and so it did. Adam however, was directly tied to that. As such, his existence as a character was also anchored with the White Fang. As such, it is inevitable that due to that and of course, due to wanting to finish Yangs and Adams rivalry, that he would be axed off. It makes sense. It was not “Only for shipping”, his death was a long time coming and even without the bees it could have just as well happened there. I really hate this extreme of the argument mainly because it reduces Adam and all he was/is into ONE thing, just to make an argument.
The counterpoint to that I have noticed more often than other was that it was not about shipping at all. Another extreme which completely ignores context and what is shown. I will be honest with you all, while I do not think that Adam was killed for bumblebee, his death was used to prop it up regardless. With such lines as “What does she see in you”, the hand holding etc. Sorry, but this was used to ship, very obviously even since it utilizes a romantic trope of new replacing the old. We have to consider the out of show context too in this case, since the voice actor of Blake was very vocal afterwards with the whole bumblebee ship thing and questions about it. I also find it a bit hypocritical because the same people stating that Adams death had nothing to do with bumblebee are most of the ones who started posting bumblebee supporting stuff on twitter and other social media at exactly THAT time.

Adams strength

We come to the next point of contention of the fight. And it is the strength of Adam. One side Claims that Adam was nerfed very much for a fight against Yang and Blake, the other side claims that he was always at that strength level. And…. Welll….. I hate to do this. But BOTH sides are right in this case! Before you crucify me, please let me explain.
RWBY as a show has always had problem with power levels, or at least, relative power levels of characters compared to other characters. V2 is a PERFECT example of power levels being fucked completely. So now we have Adam. A character designed as Vergil and Jetstream Sam, a badass that we have seen cutting huge robots into non-existence with his semblance, and that is about it. The rest of his achievements are mired in doubt. In V3 he “fights” both Blake and Yang. But Blake doesn’t even fight him, it’s him bashing her around as if he was a deadbeat husband. And we don’t even know if Yang fought anyone before she encounters Adam and things like that. Sienna he just stealthily executes. And that is about it.
His strength has never been portrayed properly and inevitably people had to fill in the blanks, for those who see Adam as strong, there was no need to fill anything in as they know what they have seen and interpreted it directly. For those who see Adam as weak, they interpret it differently and see his actions as a sign of a weak man who never actually has a direct fight against his opponents.
His overall threat was always unclear, so it’s no surprise that 2 opposing sides formed over its interpretation. Just look at the Jinn and Ozpins (How do I beat Salem) question, how many interpretations does THAT have?
He never had a proper fight against our heroes or anyone whose strength is establishes before V6. How can anyone really make a judgment on his strength when we can’t even properly measure it against other characters?

Adam being “murdered”

I know that this is supposed to be a middle ground segment but I have to say, that there are cases where the middle ground is simply not there, where the choice is binary an there is a right and a wrong one. This is one of those cases. An argument is made by the side that is on Adams “side”, that he was murdered by Yang. I do not know how this “argument” started, was it a joke, or was it serious, but it became a rallying point for some of those that were dissatisfied with Adams demise.
And I have to say. Stop. Guys… Just stop. You are not defending Adam like this, you are making it worse with, quite frankly the huge reach that the “Yang murdered Adam” thing is. It’s the same reason why I dislike some of Bumblebee, it’s because of the massive reaches that are being made. Neither Yang nor Blake “murdered” Adam. Adam was a psychologically unstable terrorist, he was trying to kill them, and we have to remember that both Yang and Blake are just out of their teenage years, so they WILL respond even lethally, especially considering the happenings of V3. They killed him in self-defense, yes, even Yang. I hate to bring politics into this, but I have to make an example, the Police. An argument can be made that they COULD not kill as many people in confrontations, that they COULD use more non-lethal options. But here is the thing, combat is not as easy as that. You don’t have time for decisions, you don’t have time to evaluate if the threat is deadly or not. I am not a policeman but I have gotten into my fair share of fights, there is no time to consider things or think them over, you fight till the opposition is down. The next point is a bit related to that

Yangs PTSD during the fight

I know that posts exist from those who have had PTSD, I am not going to deny their experiences, but, while personal, they do not give the full picture of PTSD nor do they fully consider the context or PTSD in its entirety, I might make a thread on it, but I will shortly cover it here. The disagreement here is simple, one side thinks Yangs PTSD was handled badly (Specifically in this fight) and the other things the opposite.
(One of the posts in question https://www.reddit.com/RWBY/comments/aq77ky/do\_people\_actually\_know\_what\_having\_ptsd\_is\_like/)
I have studied psychology for a few years in high school, I know, that is not high qualification, however, this gave me access to case studies and other types of studies from many various medical and non-medical databases from all over the world, the database is called EBSCO for those who are wondering, to access it you will need permission from your local library if I am not mistaken. But to move on to the PTSD. I did my research on it through this database, case studies, conclusions, things like that.
The fight is mixed on how well it is done on that front I think from my research on PTSD. She does not react as she is supposed to. The post in question correctly states that the body wants to stop a perceive threat, so adrenaline kicks in. The post then states that it makes sense for Yang to not break down and instead fight, yes, I agree. But her being portrayed in the fight, does not coincide with what should be the case. I agree she isn’t supposed to break down, instead, she was supposed to go into an uncontrolled rage. Remember, a glass shattering was enough to give her a flashback and engage her adrenaline, since there is no threat, she goes into a shock. In this case, she is facing the same enemy that gave her PTSD, yet she remains calm during the confrontation most of the time until the end.
She was not supposed to break down, when the fight started, she was supposed to turn into basically a berserker, because PTSD overloads you with adrenaline which fucks you over completely. Adrenaline does not make you calm, it does the opposite. And I know what it feels like to be overloaded with adrenaline, not a PTSD moment, but when fighting, you don’t think straight, you burn up, you have the energy, the body moves and the brain is left somewhere else. I have lashed out at people undeserving while in such a state, I have taken hits that would have otherwise made me reel on the ground from the pain. And that is just the NORMAL amount of adrenaline in fighting, getting the PTSD amount, when your body might as well think that you are in MORTAL danger? Yeah, that would be worse. And yet Yang is calm until he starts taunting her. That is simply not how PTSD works. If a glass was enough to break her, the real guy would have made her go berserk. It didn’t.
Again, I am not denying the experience of the poster of the thread I linked above, however, I do not think the full context of the fight and PTSD is considered.
But do remember, I said that the portrayal was mixed right? Well, it was. Because I think that the end of the fight is where the writers got it right. Its Yang stabbing Adam in the back, she is clearly fucked up by that point, she is not thinking, she just wants to end the threat by any means necessary. Her expression while attacking, the whole need to attack Adam in such a way, THAT was good in regards to PTSD. She wasn’t thinking, she was acting.

Conclussion

I think that both parts of the divide have some really bad extreme positions they have taken JUST to oppose the other side in any way possible. I want both sides to at least acknowledge that the other side to theirs have legitimate criticisms and arguments over the fight, that it’s not all about shipping and things like that, that it’s not all blind Adam fans defending him.

Please visit RWBYcriticsfor more discussions on topics you might agree/dissagree with in RWBY. We do not want to become an echo chamber and welcome all opinions as long as they are argued upon and not simply stated. If you do not like what you find, we welcome you to be people who change it, if you so wish.
(Please, if you do not want to, do not join the sub, or say it in PM's with your reasonings, instead of the thread, i do not want the entire thread to be derailed just because of his one single tibbid, thank for you for understanding and keeping to the topic on hand)
submitted by Dextixer to RWBY [link] [comments]

Difference Between Forex and Binary Options Trading ... ★ ★ Binary option robot review - Pro Binary Robot Review is it real or Scam?★ ★ The Best Candlestick Patterns : Candlestick Types Forex ... Pro Binary Option System Of 2017 Binary Options Trading - Binary Options - The Best Binary Options Trading Guide for 2017 Best binary options strategy - Types of binary options ... BEST 5 BINARY OPTIONS BROKERS IN 2020 - YouTube Binary Options Breakout Strategy Types of Binary Options Strategy - Online Binary Options ... NEVER LOSS USING CANDLESTICKS ANALYSIS 10 wins  binary ...

Welcome to the largest expert guide to binary options and binary trading online. BinaryOptions.net has educated traders globally since 2011 and all our articles are written by professionals who make a living in the finance industry and online trading. We have close to a thousand articles and reviews to guide you to be a more profitable trader in 2020 no matter what your current experience ... Most of you already know what binary options are, as you are here for the top tips and tricks on trading binary options. But, for the uninitiated, we will give a short brief. Binary Options are financial instruments that allow you to trade on all kinds of assets such as forex, stocks, futures, crypto, indices, and much more. There are only two ... You’ll learn much more about type checks and other prop validations further down this page. Passing Static or Dynamic Props. So far, you’ve seen props passed a static value, like in: < blog-post title = "My journey with Vue" > </ blog-post > You’ve also seen props assigned dynamically with v-bind, such as in: <!-- Dynamically assign the value of a variable --> < blog-post v-bind:title ... Binary Options Indicators, unlike forex indicators, have their own specifics. In order to make a profit on binary options trading, it does not matter how many pips the price goes. What matters is only the direction of the price movement. Despite this, many forex indicators can work fine in binary options trading. Only need to make adjustments to the trade itself and the interpretation of ... Real advantages of binary options trading. Binary option, as an exchange trade tool, has become more and more popular in recent times. The main advantages are: • The possible profits or losses are certain during the trade contraction; • This type of trading requires no special knowledge around the finance sphere and realizes on the basis of one indicator – price variance. • If the ... Symbols - Type the symbols separated by comma ", " Example: EURUSD, GBPUSD, AUDUSD, XAUUSD. You can select up to 9 different timeframes. Timeframes Count - The number of timeframes you want to monitor. INTEGRATED ALERTS . The scanner alerts you when there is a setup to the instruments you are monitoring! Popup, Sound, Email and Push Notifications available. NEVER MISS AN EXIT SIGNAL AGAIN! GET ... Although all signal services may not support each type, the most common types of binary options you can use to trade with include: Down, low or put and up, high or call binaries. You can use these ... As a binary options trader, you are familiar with the fact that there are many different ways you can trade—numerous assets and trade types. A firm can give you access to even more assets and even more types of trades. You may very well find that what you excel at is a certain type of niche trade that is not available to you on your own. In fact, you may discover new ways to trade that you ... Binary Options trading are known for their simplicity and all-or-nothing nature. Moreover, a few reasons are behind to give this trading type name binary option. Options are derivative instruments. It can be traded as forex pairs, cryptos, stocks, indices, commodities, etc. Sunday, 20 August 2017. Prop Type Binary Options

[index] [474] [17606] [28932] [13564] [15690] [21323] [24705] [11847] [13043] [22577]

Difference Between Forex and Binary Options Trading ...

The Difference Between Forex and Binary Options Trading - Binary Option vs Forex Trading Tutorial. Follow the link below to create a FREE Practice Account: h... in this channel a lot to talk about trading strategies. like the following important points that traders should know. including: 1. how to read good trends 2... Top 5 TRUSTED BINARY OPTION BROKERS:1. 💲💹IQ Option: http://www.cryptobinarylivingway.com/IQOption12. 💲💹Pocket Option: http://www.cryptobinarylivingway.com ... With binary options, besides options trading and enjoying yields of up to 92% binary options trading - Conservative binary options trading strategy introduction to binary options trading. Freedom ... The Best Candlestick Patterns to Profit in Forex and binary - For Beginners trading forex, forex strategy, forex,Online Trading Strategy #binary_options #bin... https://bitcointrader.software/?aff=3453 https://theethereumcode.software/?aff... https://www.topinvesto.com/ Email: [email protected] Hi, In this vi... Binary options are a way for people to trade on the fluctuations of price in a range of worldwide markets. Binary options are growing in popularity because they are simple to understand, and offer ... Types of Binary Options Strategy - Online Binary Options Trading ️ TRADE ON DEMO http://iqopts.com/start ️ TRADE ON REAL MONEY http://iqopts.com/bonus ... Real Binary Options Reviews 45,916 views 34:59 Bollinger Bands Indicator Strategy Powerfull Trading Strategy binary IQ Options NEWZELAND & US - Duration: 14:38. 2017 best binary option pro system. Don't be left out, opt in and make 2017 a better year financially. Money Must Be Made with Pro Binary Option System.

https://arab-binary-option.primfolgspeken.tk